[Tickets #12773] Re: Thunderbird lightning caldav serial event time failure with summer/wintertime change

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12773
------------------------------------------------------------------------------
  Ticket             | 12773
  Updated By         | benrose at math.princeton.edu
  Summary            | Thunderbird lightning caldav serial event time failure
                     | with summer/wintertime change
  Queue              | Kronolith
  Version            | 4.1.3
  Type               | Bug
  State              | Not A Bug
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


benrose at math.princeton.edu (2014-03-04 02:09) wrote:

Hi,

Some proper testing and bug documentation needs to be done here. I am  
experiencing this same bug in our installation. I have exported both  
caldav and ics versions to lightning and evolution on Linux and I see  
the off-by-one-hour behavior. I also see the off-by-one-hour behavior  
in lightning on Mac OSX. The events were created via lightning on both  
Linux and Mac among multiple user accounts. I do not subscribe to  
activesync for any of these clients, so I haven't put the calendar  
into my android, but it is not acceptable to say that one client in  
particular works therefore the whole package works. Google software  
does a lot of stuff behind the scenes. An additional point of interest  
is that once my event that was originally scheduled for 2pm is now at  
3pm, if I attempt to move the item back to 2pm, the server update  
always fails. Upstream, please test without activesync, use a  
Linux/Mac host and either evolution or lightning which are broken for  
myself and  my users. Bottom line, to channel Linus: "the end user  
doesn't care."

I am trying to help out, I am looking through the horde code currently  
to see if we could perhaps make a special exception depending on the  
client software. Right now I am reduced to modifying the database each  
time daylight savings comes about, something like:

select * from kronolith_events where `event_creator_id`='USERNAME' and  
`event_recurtype`!=0 order by event_id desc \G

will show you a list of events that need to be tweaked up an hour or  
back an hour depending on which user you want to "tweak". But this  
isn't a perfect solution, if the user scrolls too far ahead in their  
calendar, the event is still at the wrong time. So it could be a  
problem when you're scheduling for next week (6 days from right now is  
DST in NYC).

TL;DR: PLEASE RECLASSIFY THIS TICKET TO OPEN NEEDING INVESTIGATION!

>> I just tried this in Lightning. I created a new recurring event in my
>> local timezone, which observes DST. The event was successfully
>> created in lightning, synchronized to Horde and synchronized from
>> Horde to all of my currently connected activesync clients.
>
> you have to test via caldav and lightning only, this bug does not  
> apear via active sync to i.e my android phone 4.2 !!! This seems the  
> best argument that it is a lightning bug, or at minimum a  
> conversation bug between horde and lightning via caldav only
>
>>
>> On ALL clients the event appeared to occur at the correct time,
>> regardless of how many DST transitions have occurred between the
>> start of the series and the instance I was looking at.
>>
>> Going to mark this not a bug until somebody can provide data to allow
>> a developer reproduce this.
>