KEP2: Modification of datetime type, introduction of 'tz' sub-tag (wiki revision 10645 of 2010-11-19)

[Georg C. F. Greve]

Hi all,

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

	http://wiki.kolab.org/User:Greve/Drafts:KEP:2

All comments should again go to kolab-format at kolab.org.


A summary of some important points raised & considered:

*RFC3339*

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,

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101119/f11699b8/attachment.sig>