Why and when storing local time? (Re: Basic rationale of the KEP #2 design)
Georg C. F. Greve
greve at kolabsys.com
Thu Mar 31 12:30:11 CEST 2011
On Thursday 31 March 2011 12.11:26 Florian v. Samson wrote:
> 2. the offsets relative to UTC for the regular (i.e. non-DST) and DST
> definition of that TZ; these changes are really rare, I do not remember
> major, well populated regions changing their offsets to UTC for decades.
Russia is currently planning just that, it was in the news last week.
Turkey has twiddled with the DST switch this year, as well.
Both Russia & Turkey would count as major, well populated regions for me.
> 3. the two DST switching dates (forth and back): even though the whole issue
> with the lacking TZ-information in Kolab-objects was triggered by the
> effects of the politically motivated change (in 2005) of the DST switching
> dates in the North American TZs (becoming effective in 2007), TZ-data
> changes of this category also happen rather seldom.
Two major regions changing rules just this year, the U.S. doing it in 2005,
possibly reverting the change again in a year or two for reasons of
practicality, is admittedly rare in comparison to some other political
But it was the U.S. shift in 2005/2007 that according to what you told me made
you miss conference calls under US participation/governance, which you at the
time described as a major issue and defect.
Switching to static encoding would preserve that defective behaviour, although
the underlying mechanisms would be different.
> The principal issue to solve is still that the current Kolab-format fails to
> capture the TZ in which an event is happening at all!
Agreed. KEP 2 resolves that issue fully.
So if this is the major issue to resolve, speeding adoption up would have
seemed like a good idea. But the process cannot just ignore other issues when
they are brought up, so we'll have to drill to the ground of these again.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format