Why and when storing local time? (Re: Basic rationale of the KEP #2 design)

[Georg C. F. Greve]

On Thursday 24 March 2011 11.12:42 Jeroen van Meeuwen (Kolab Systems) wrote:
> Consider this: Normally, the offset to UTC for Berlin is +0100. This is the
> baseline offset  to UTC for Europe/Berlin. In the summer, in a political whim
> decades old, Berlin has DST, adding an additional hour to the offset to UTC.
> This does not, however, change the baseline offset to UTC for Berlin, still 
> +0100.

Correct.

Now take this example one step further.

A user in Berlin sets an appointment for 10:00 in Europe/Berlin.

With your notification it no longer matter whether they do it in the summer or 
winter, it always gets written into the format as 09:00 UTC.

Definitely an advantage.

Trouble is: 10:00 Europe/Berlin is 08:00 UTC.

The stored value of 09:00 UTC is 11:00 Europe/Berlin during the summer.

And personal opinions about people who introduced DST in the first place aside 
(most of which I very much share by now) this is not just some theoretical 
offset, it is the real basis for all calculations.

So in order to calculate the appointment time for any other time zone, you 
would have to pre-process the stored value by checking whether right now DST 
is in effect in Berlin, and then subtract the DST offset from the stored value 
to get the actual UTC time.

Worse, still, this is true for *all* the datetime fields.

So in order to get the *actual* creation-date, you'd first have to check DST in 
Berlin for that date in order to get UTC be able to use the value. 

That is why UTCWND != UTC.

It is undoubtedly a way to address the issue, but it adds preprocessing needs 
to all datetime fields, which in my view is inferior to storing local time in 
RFC3339 with expressed relationship to UTC.

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/20110325/bd86d930/attachment.sig>