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

[Jeroen van Meeuwen (Kolab Systems)]

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 
currency.

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 
complexity.

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>