Re: KEP2: Modification of datetime type, introduction of 'tz' sub-tag (wiki revision 10645 of 2010-11-19)

[Georg C. F. Greve]

Hi all,

Try this on an example, say a person trying to store a recurring event at 10:00 in Europe/Berlin.

If they create this event in the summer, that translates to 08:00 UTC. If they create it in the winter, it translates to 09:00 UTC. Each time with tz=Europe/Berlin.

In order to calculate recurrence correctly now, you'd have to know whether the event was created in the summer or winter. But this isn't stored unless you want to try guessing backwards from the creation-date, which involves another DST calculation that could go wrong.

The reason this does not affect us for non-recurring events is that it only involves one of standard/DST and the calculation takes place when the event is created. The only potential problem would arise if the event is too far in the future and DST rules change in just the right way to throw off the calculation and the event was in a vulnerable zone.

Canonically storing "UTC calculated from standard time" solves both, but for the second case the chance of bad results is just very tiny, whereas in the first case we're guaranteed to be wrong half the year - always the other one from when the event was created.

Does that make it clearer?

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
m: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve


Sent from mobile. Please excuse brevity.