KEP 2: Modification of datetime type, introduction of 'tz' sub-tag

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Fri Nov 19 11:48:44 CET 2010


On Thursday, November 18, 2010 09:26:53 pm Bernhard Reiter wrote:
> Unless we define a specific versions of the Olson database to be used
> for a specific timeframe, several clients will have different versions.
> This would mean a client with a new database and one with an old one, e.g.
> because of long term support would display events at different times.
> 

The Olson database is used on millions (give or take a dozen) of very, very 
long term supported platforms. The reason it gets updates are two-fold;

- The history of DST and timezone changes across the world is still being 
uncovered. The Olson database has the lead in accumulating changes discovered 
throughout the world, and updates its database which contain the -to many- 
authoritative records since as early as 1926.

- DST changes / timezone for any given location is set in stone for only so 
many years into the future, and may change.

Two different versions of the Olson database will not result in a scheduling 
conflict, as the authoritative time (as described in KEP #2) will *always* be 
UTC (and an additional authoritative timezone may be specified to address any 
timezone / DST shifts and changes). The application merely uses the Olson 
database to calculate where to present the event based on the most accurate 
timezone / DST information available (to anyone) at that time, while without 
any such Olson database, no accurate record can be found in order to do just 
that.

> I believe it is better to have a self contained definition. If we would
> add the information when the timezone changes are to the format than
> all clients would display the information at the right time.
> 

How do you save the information in the event *and* update it as new 
information becomes available? And what would be the process to uncover the 
history of timezone changes and DST shifts? How will you monitor a complete 
world of autonomous entities making decisions that influence whether the 
database you ship is still accurate? Could we guarantee such database we 
maintain ourselves is in fact the most accurate record, and could we be better 
even then the existing authoritative database?

If we can get these questions answered, we might be able to rule the world in 
terms of timezones and DST information.

> A minor advantage would be that client were not required to have a full set
> of the Olson database on board (which some systems do not have I believe).

The Olson database is not a client-side requirement (although I suppose we'd 
use it if/whenever it is available), any derivative (which is what M$ does) 
is; it is the reference implementation. You can examine the differences 
between what Microsoft does and what the rest of the world thinks is an 
appropriate approach here:

  http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/zone_tzid.html

This "article" has a nice list of DOs and DONTs as well:

  http://stackoverflow.com/questions/2532729/daylight-saving-time-do-and-donts

Concerning bullet point two;

 - "Include the local time offset as is (including DST offset) when storing 
timestamps"

also implies accurate historic information is present ("CEST" for example does 
not necessarily exist forever, but clients will require an accurate display of 
such history, which is why we would choose to use "Europe/Berlin" which, as a 
reference to the geographical location (also available in Olson), short of a 
world war destroying the planet, will remain to exist forever).

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/20101119/84da8350/attachment.html>


More information about the format mailing list