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

Florian v. Samson florian.samson at bsi.bund.de
Wed Mar 23 11:13:11 CET 2011

Bernhard, Jeroen,

first of all: thanks a lot for the constructive conversation.  
Reading it helped my understanding of the issues a lot, especially 
Bernhard's explanations: this is very helpful.

Am Mittwoch, 23. März 2011 um 10:39:53 schrieb Bernhard Reiter:
>  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.

Bernhard, I think you mean a "timezone definition change", not a "timezone 
change": then this statement sure hold true, but this is not what you 

A "timezone change" would require altering the TZ-ID (as Jeroen explained 
with the example of some counties in Indiana, USA) and thus completely 
exchanging TZ-data (as this is in a different time-zone, than before).

> > 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 predict 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?

I intended to express my strong opposition to your statement "imprecise 
wording does not matter": well, here you can see that it does matter a lot 
as it can lead to endless misunderstandings and mislead people into 
thinking they are on the same track, though in truth the just use the same 
words, but mean completely different things!  
So we cannot simply call "blue" "red" or define "static" to mean "dynamic": 
this did and will continue to lead to utter confusion.


More information about the format mailing list