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

[Jeroen van Meeuwen (Kolab Systems)]

Georg C. F. Greve wrote:
> 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.
> 

Some of the time, the latter statement in itself may hold true now and for the 
foreseeable future, but the former is completely invalid.

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

No, the stored *data* is 09:00 UTC "Europe/Berlin", not "whatever is the 
equivalent in Europe/Berlin of whenever 090:00 UTC occurs".

> 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.
> 

With local time, the inverse would be true. For 10:00 Europe/Berlin, depending 
on DST in Europe/Berlin, the actual UTC timestamp is X, which I can then 
represent accurately taking my own offset into account. This, contrary to your 
false statements above and below this comment, would in fact effectively need 
to be applied to *all* datetimes should they be stored in local 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.
> 

No, the creation-date, modification-date, etc. are actual, immutable UTC 
timestamps with which no 'tz' attribute is to be stored.

> 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.
> 

No it doesn't add preprocessing.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20110327/f66020e8/attachment.html>