KEP2: Modification of datetime type, introduction of 'tz' sub-tag (wiki revision 10645 of 2010-11-19)
Georg C. F. Greve
greve at kolabsys.com
Fri Nov 19 12:13:21 CET 2010
Thank you very much for the extremely good input!
There was a lot in there that I believe was actually worth preserving for
future Kolab contributors who might wonder about what has been considered
during this thought process, and to hopefully better understand what will in
the end turn out to be our decision.
Simultaneously, Jeroen has done a lot of work on the tooling, and together we
spent substantial time thinking about process. That is far from finished, and
will need its own discussion to come to a decision.
But in the meantime, I'd like to start using the Wiki + Git approach to keep
track of edits, and to make the document available with nice markup & such for
better reading. You can find the latest draft incorporating the comments at
All comments should again go to kolab-format at kolab.org.
A summary of some important points raised & considered:
This is not so much a change, as a documentation of existing practice, which
suggests clients are already using the system functions for reading/writing
datetime stamps, which are based upon RFC3339.
The only reason to not do this update would be if there were any clients out
there that are known to have their own parsing/writing code for datetime, and
a strong rationale why they are not using system libraries.
Do we know of any such cases?
*Use of database vs static encoding of DST data*
Static encoding has the obvious disadvantage that it cannot adapt to changing
legislation, which led to the very mixed results for iCalendar that were
outlined by Andrew McMillan. Simultaneously, the primary weakness of local
databases, which is potentially out of date information, is likely to be
resolved by adoption of the IETF draft for a Timezone Service Protocol.
*Usage of the Olson database*
In order to ensure that clients don't write just ANY place in the world into
the tz fields, choosing a database of reference location is the sensible thing
to do. When it comes to choosing which reference, the Olson database seems the
closest thing to a generally accepted and widely used table.
Windows appears to be the only system again going its own path, but
fortunately there is mapping to Windows time zones provided by the Unicode
Common Locale Data Repository (CLDR).
So right now I still think use of the Olson database is the best of an
imperfect set of options. But if there is something I am missing, I'd be glad
to hear what it is that I missed.
Comments and suggestions very much welcome,
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format