Why and when storing local time? (Re: Basic rationale of the KEP #2 design)
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Mon Mar 21 15:41:53 CET 2011
Georg C. F. Greve wrote:
> On Friday 18 March 2011 17.39:48 Florian v. Samson wrote:
> > IMHU he proposed UTC + TZ-ID.
> Actually Jeroen proposed UTCWND stored as RFC3339 + TZ-ID.
> Where UTCWND = UTC With No DST, an artificial time zone that looks like UTC
> but ignores DST and maps the world as if DST did not exist.
> But because DST exists, it is different to UTC and ultimately moves the
> ambiguity to the relationship between UTCWND and UTC.
I recon UTC is not an articial timezone. I can fairly confidently state most
the rest of the world agrees with me. UTC is not (read: cannot be) different
to UTC. UTC "without DST" does not exist, because UTC has no DST to begin
As such, there is no ambiguity between UTC w/o DST and UTC (w/ DST) or UTC -
only one of which actually exists.
What is different is the interpretation of the data when presented to the
parser, something completely different from the interpretation of the data
when presented to a human -both in read and write scenarios alike.
The notation would be Zulu (strict writing). I recommend parsers are being
(strongly) recommended to be able to parse any RFC 3339 compatible notation -
though always UTC (loose parsing).
To indicate the UTC timestamp is to be interpreted (by the parser, not the
human) different, and thus likely to have to be presented different, the 'tz'
attribute can be used. This would apply to 1) recurring events, 2) events in
the future (insert the argument on DST predictability).
Using the 'tz' attribute with a UTC datetime suffices to make the mapping
between what is on the data layer versus what should be 1) presented on
screen, 2) written back to the data layer.
With UTC datetimes conform the notation formats specified in RFC 3339,
programs can use system library functions to get the raw data out if such
functions exist or write their own. We preserve a level of backwards
compatibility with older clients (older parser libraries actually).
Without UTC datetimes, if specified to need to conform to RFC 3339 notation
formats, programs cannot use any system library functions to get the raw data
out, because an ambiguous -if not false and/or invalid- offset may be included
in the raw data, negating the value of the data that is obtained through such
Without UTC datetimes, if specified to not need to conform to any existing
specification -let alone approved in the Internet Society- we have to invent
our own datetime notation format unlikely to find adoption beyond Kolab XML
parsers, likely hindering further adoption of application compatibility with
the Kolab Format, definitely hindering the Kolab Format from ever becoming a
widely accepted, standard Groupware Format.
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the format