KEP2: Modification of datetime type, introduction of 'tz' =?utf-8?q?sub-tag=09?=(wiki revision 10645 of 2010-11-19)

[Hendrik Helwich]

Hi Georg,

Am Donnerstag, 16. Dezember 2010 20:30:49 schrieb 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.

i think it is not nice to store a wrong UTC time half the year. This is 
complex and can confuse people.
Also technically it is possible that the standard time changes for a time 
zone. This would break the hole concept.
I am not sure if this could happen in practice but from the format it is 
possible.

So if already a wrong UTC time is stored half the year it could also be stored 
wrong for the hole year by storing directly the local time as UTC. This will 
be less error-prone.

But IMO it would be much nicer to store local times in a different format than 
UTC e.g. by dismissing the trailing 'Z' character. This will result in a more 
readable Kolab XML and is less error-prone. The disadvantage will be that the 
RFC3339 syntax will be broken, but i think this would be the smaller problem.
The syntax of the datetime should match the needs of the Kolab XML. If the 
RFC3339 syntax does not match to that need it should be adapted in that case 
IMO. RFC3339 seems not to be intended to store local times with it.

Best regards,
Hendrik

> Does that make it clearer?
>
> Best regards,
> Georg