Recurring events with timezone
Gunnar Wrobel
wrobel at kolabsys.com
Mon Oct 11 15:22:16 CEST 2010
Zitat von "Georg C. F. Greve" <greve at kolabsys.com>:
> Hi Hendrik,
>
> On Monday 11 October 2010 10.55:58 Hendrik Helwich wrote:
>> The problem here is that the difference of the UTC time to the local time
>> changes in some timezones (like in germany) due to the daylight saving
>> time. So in germany the difference is two hours in the summer and one hour
>> in the winter. If you have a recurring event it could cross this border.
>
> This vaguely reminds me of the date field discussions we had about
> OOXML, where
> Microsoft wanted to keep its (known broken) date format.
>
> Storing in a variable base seems fundamentally broken to me, in particular
> when you take multiple time zones into account. So when a meeting takes place
> in two timezones which switch to daylight saving time at different
> times, when
> is that meeting supposed to be? Which of the local time stores wins?
>
> If it is stored in UTC, at least there is a firm point of reference against
> which it can be calculated. But there should be some way to identify what
> happens in these DST conflicts. IIRC my discussions with Bernhard
> that has been
> on the list of issues to resolve for the format for some time now.
>
> So the question is: What would be the right way of treating it?
>
> Storage in UTC, as before, with an additional field that defines the
> behaviour
> for DST? I could envision such a field to define that an event (a) stays with
> UTC, or that (b) it stays synchronous with local time zone X.
I think this makes most sense. Basically just storing the timezone
alongside the event and pretty much what Andrew also suggested in his
mail. Sounds simple enough.
I just wonder if there was anything that was discussed before that
would indicate that there are problems with this approach. Because it
seems simple enough to add to the format definition.
>
> That might be a clean solution. But how would this work with synchronization,
> e.g. the ActiveSync protocol? Does anyone know off the top of their head how
> this is handled there?
Just asked my personal ActiveSync advisor and he mentioned that for
ActiveSync "the server sends a timezone object to the client for each
event. Not *each* event, there are rules for when it's necessary. But
the timezone object is a confusing binary string that describes the
event's original timezone. The event time itself is communicated via
UTC."
Cheers,
Gunnar
>
> Best regards,
> Georg
>
>
> --
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Zürich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
>
--
Gunnar Wrobel
Developer, Kolab Systems AG
e: wrobel at kolabsys.com
t: +49 700 6245 0000
w: http://www.kolabsys.com
pgp: 9703 43BE
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
More information about the format
mailing list