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

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Thu Mar 24 11:12:42 CET 2011


Bernhard Reiter wrote:
>  Am Dienstag, 22. März 2011 23:26:18 schrieb Jeroen van Meeuwen (Kolab
> 
> Systems):
> > > See my other post about why I currently believe that saving Localtime +
> > > TZ-ID will be better than UTC + TZ-ID. Do you share the argument?
> > 
> > Only in part, as timezone changes (not the same as DST changes)
> 
> Just to clarify:
> To me the tz-data of a specific timezone contains the daylight saving
> rules. So when the daylight saving rules change, the tz-data change.
> 
> In my writings a tz-data change was equivalent of a timezone change.
> 

In which case I completely disagree with the argument, quoted below for 
convenience:

Bernhard Reiter wrote:
> An example: As a user I want 10:00 in Winter Berlin/Time, which TZ-data is
> UTC+1 at the time I create the event for the date I am creating it.
> 
> Saving 1) UTC + TZ-ID: "9:00 + Europe/Berlin"
>        2) Localtime + TZ-ID: "10:00 + Europe/Berlin"
> 
> Now TZ-data for Berlin changes to UTC+2 for that date.

I'm sorry this confused me in that you said "winter" but was apparently 
talking about DST.

Bernhard Reiter wrote:
> Variant 2) still works, I am still at 10:00 in Berlin as ii) demands.
> But for 1), if I just apply the new TZ-data, I end up with 11:00 Berlin.
> 

Variant 1) works too, if the specification is to write and read the datetime 
as the timestamp corresponding with the target time using the baseline UTC 
offset only, as previously explained:

Jeroen van Meeuwen wrote:
> (...) specify clients must write out the datetime as if DST was never 
> invented, and only use their baseline offset; two situations for writing the 
> data out exist:
> 
> - During the summer, user decides he wants a weekly 11am company meeting and 
> is in Zurich.
> - Writes out 10 UTC, Europe/Zurich, as the baseline offset is +1 -and does not 
> write out 9 UTC accounting for the current DST offset to UTC.
> 
> - During the winter, user decides he wants a weekly 11am company meeting and 
> is in Zurich,
> - Writes out 10 UTC, Europe/Zurich, as the baseline offset is +1
> 
> - All clients know the baseline UTC offset for Zurich is +1, and the DST 
> offset for Zurich is +2.
> - The local baseline UTC offset is known (0 for me in this case), and the DST 
> information for my location is available too; +1. In my case, this cancels the 
> +1 Zurich is also experiencing.
> 
> - Employee in South Africa/Cape Town must call in at 11am in the summer; 
> knowing the UTC offset for Zurich at that moment is +2, it's timestamp minus 2 
> (negate Zurich offset) + 2 (Cape Town offset).
> 
> - Employee in South Africa/Cape Town must call in at 12am in the winter; 
> knowing the UTC offset for Zurich at that moment is +1, it's timestamp minus 1 
> (negate Zurich offset) + 2 (Cape Town offset)."""
> 

From http://kolab.org/pipermail/kolab-format/2011-March/001256.html

> > Additionally, these (sorts of) timezone changes for a geographical
> > location are known in tzdata for a good part of the future, so the
> > client can correct this if needed.
> 
> My argument is based on the assumption cannot predice the tz-data changes
> for the future? You are saying that this is true for parts of the tz-data,
> which then supports my argument? As this is a tz-data change.
> 
> What am I missing here to understand you?
> 

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.

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/20110324/74f31537/attachment.html>


More information about the format mailing list