Tickets :: Comment on [#12773] Horde_Timezone unable to use non-ftp scheme to access database.

* Your Email Address
* Spam protection	Enter the letters below: __ . .__.. .. . / `\| \| \|\|\ \|\|\ \| \__.\|___\|__\\| \\|\| \\|
Comment	> 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.
Attachment
Watch this ticket

Saved Queries