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