[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         | herde at tuhh.de <herde at tuhh.de>
  Summary            | Thunderbird lightning caldav serial event time failure
                     | with summer/wintertime change
  Queue              | Kronolith
  Version            | 4.1.3
  Type               | Bug
  State              | Unconfirmed
  Priority           | 3. High
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


natanji at gmail.com (2014-01-09 13:52) wrote:

This is definitely a bug in Kronolith, not in Thunderbird. Here is why:

The event is created in a local timezone (Europe/Berlin). This  
timezone does not have a fixed offset to UTC, but one that changes  
with DST. That is expected behaviour for ALL local timezones. A  
recurring event in this timezone is expected to start at the same time  
(i.e. 19:00) in both winter and summer. This means that this local  
time converted to UTC is different for this event in winter and summer!

Now Kronolith internally uses UTC to represent the event. That is  
beneficial for many purposes. But the Kronolith developers seemingly  
didn't think about *repeated* events here. If we repeat an event with  
*fixed* time in UTC (every repetition is at 19:00 in UTC), this will  
mean a non-fixed time in local timezones.

By definition of RRULE in RFC 5545  
(https://tools.ietf.org/html/rfc5545#section-3.8.5.3), this is a bug  
in Kronolith. To see this, just look at the examples:

       Every other day - forever:

        DTSTART;TZID=America/New_York:19970902T090000
        RRULE:FREQ=DAILY;INTERVAL=2

        ==> (1997 9:00 AM EDT) September 2,4,6,8...24,26,28,30;
                               October 2,4,6...20,22,24
            (1997 9:00 AM EST) October 26,28,30;
                               November 1,3,5,7...25,27,29;
                               December 1,3,...

-> When DTSTART is given as local time zone, then some events are  
created at 9:00 AM EDT, some at 9:00 AM EST. EDT and EST have a  
different time offset to UTC.

On the other hand, Thunderbird Lightning handles this case correctly:  
when DTSTART is given in UTC, then this means there literally is no  
DST to take care of. The event would happen at 9:00 AM in the chosen  
time (UTC), and will be offset in local time sometimes - and not at  
other times. The RFC is aware of this:
       (...) In most cases, a
       "DTSTART" property of DATE-TIME value type used with a recurrence
       rule, should be specified as a date with local time and time zone
       reference to make sure all the recurrence instances start at the
       same local time regardless of time zone changes.

Note: I believe this bug does not affect some other clients simply  
because they incorrectly implement RFC 5545. When you FIRST convert  
the start time into your local timezone, and THEN apply RRULE to get  
the recurrence set, everything seems fine. And many clients seem to do  
just that, and few people every notice this as a problem because they  
only use one local time anyway, and want this kind of behaviour.

Further note: in Owncloud, this bug does not happen. So SabreDAV (used  
by both OC and Horde) is not responsible.