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.

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/20110321/2cb81809/attachment.html>

More information about the format mailing list