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 12:29:11 CET 2011

Bernhard Reiter wrote:
> Am Donnerstag, 24. März 2011 11:12:42 schrieb Jeroen van Meeuwen (Kolab
> Systems):
> > 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
> Your version of using the "baseline" UTC offset only works,
> if this part of the tz-data does not change. I was proposing a solution
> for a non-daylight saving rule change in the tz-data.

This, however, hasn't happened since quite a while, as it is, as I've 
explained, much too intrusive this day and age, to too many primary 
stakeholders, in too many sectors of global trade. That said, *should* it 
happen there's advance notice not unlike there was for the adoption of the EUR 

That said, changing the entire format to use local time, generating 
incompatibility, non-standard, ambiguous notation formats, for *all* of what 
is to be written in Kolab XML, just because using UTC is mistakenly and/or 
wrongly assumed and/or perceived to be insufficient/ambiguous/faulty/unfit 
seems... overkill.

> My reading of rfc3339: Using a "baseline" UTC offset would not
> be local time as mentioned in "4.2 Local Offsets". Furthermore, the rules
> you propose seem to be much more complicated.

A baseline UTC offset is not a local time indeed... they're two completely 
different things.

Section 4.2 does not apply, as no local offsets are to be saved to the data if 
the datetime is in UTC - with, of course, Zulu notation.

As for the complexity, despite the fact I don't see it that way, I suppose 
that's one of many reasons to let up-to-spec software handle the data, and not 
humans. The problem is the inverse of that same argument, not the level of 

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/62b607c1/attachment.html>

More information about the format mailing list