Recurring events with timezone

[Georg C. F. Greve]

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.

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?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101011/4f626984/attachment.sig>