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
> 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:
This "article" has a nice list of DOs and DONTs as well:
Concerning bullet point two;
- "Include the local time offset as is (including DST offset) when storing
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).
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