Why and when storing local time? (Re: Basic rationale of the KEP #2 design)
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Sun Mar 27 21:17:14 CEST 2011
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.
> 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.
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the format