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.

Best regards,

Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110331/dd17c47f/attachment.sig>

More information about the format mailing list