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

noreply at bugs.horde.org noreply at bugs.horde.org
Tue Mar 4 13:39:59 UTC 2014


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 13:39) wrote:

Some more testing reveals I have the off-by-one-hour behavior also in  
the Horde webview kronolith itself, and in outlook clients subscribed  
via ical. Events afflicted were created using Linux and Mac, both via  
lightning and inside the kronolith webgui itself! This is pretty  

> 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).
>>> 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.

More information about the bugs mailing list