UPDATE: KEP 2: Modification of datetime type: introduction of 'tz' attribute (revision #10739)

[Georg C. F. Greve]

Hi all,

I have to thank Hendrik and Joon for keeping discussing the UTC issue, because 
they made me realize that there is one more use case for which the problem 
exists, and we probably just never caught it because it is fairly esoterical, 
and when it happens would be discarded as "odd freaky behaviour I cannot 
explain but since it did not occur again, I'll forget about it."

The issue is explained here:

http://wiki.kolab.org/User:Greve/Drafts:KEP:2#Single.2C_Non-Recurring_Events

The root cause of the issue and the reason noone caught this before is that we 
all tend to see UTC as unambiguous and universal, because that is what it was 
designed to be and what we were told it is. But from the perspective of 
someone living in a DST regime, it is in fact quite ambiguous:

http://wiki.kolab.org/User:Greve/Drafts:KEP:2#Ambiguity_in_UTC_storage

Fortunately this is fairly easily resolved if we simply always store in UTC 
calculated from standard time, and let DST calculations do their job when 
necessary.

But it means that *all* events should switch to "UTC calculated from standard 
time for the target time zone" - even the non-recurring ones, and even the 
creation and modification timestamps, provided we want them guaranteed 
unambiguous.

But naturally it is totally possible that all this has my brain in knots, so 
better take a look at the latest version, which you can find here:

	http://wiki.kolab.org/User:Greve/Drafts:KEP:2

Comments to kolab-format@, as usual, please.

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/20101219/cbe67e0c/attachment.sig>