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
Tue Dec 7 18:44:34 CET 2010
Thank you for your input.
But I have to say that I am a bit puzzled. Which part of
"For object types [...], clients *MUST* use the Zulu notation for datetime
fields, so YYYY-MM DDTHH:MM:SSZ with 'T' and 'Z' as the literal characters. "
do you see allowing all the various expressions RFC3339 allows?
This is about parsing only, with an eye on two factors:
As Jeroen correctly pointed out, clients already must be able to parse this,
as it is part of the email standard, which encapsulates the Kolab objects, not
to mention that a full Kolab client is also a MUA.
So this is about using one routine for parsing, instead of multiple routines,
reducing the possibility of bugs and unforeseen issues in the maintenance of
the code, which follows the principle you so wisely quoted:
"Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away."
-- Antoine de Saint-Exupery
So let's leave away that additional parser.
And finally, by not specifying our own datetime format, we retain the option
for future extension of Kolab, for there might be objects that will require
other expressions, eg the additional precision RFC3339 offers.
This would be lost in the conversion you suggest, thus breaking the future use
case, and then requiring another change of format which will affect all clients
again, instead of being a gradual upgrade later that only affects the clients
which want to make use of this.
The alternative would be to intruduce two mutually exclusive datetime stamps
in the format, which would again violate the principle you qoted.
The current state of the proposal makes sure that clients have a long period
to ensure they follow the "be liberal what you accept, but strict in what you
write" approach which Henrik from your project advocated in this discussion.
Only last week he said that he found this an acceptable approach, so I am a
tad surprised this gets brought up again now.
On a technical note, I am not sure how including the code snippet for parsing
you're referring to is easier and more robust than using one of the built-in
constructors, e.g. java.text.SimpleDateFormat .
The same would be true for PHP5, for instance, e.g this older article, 
which is probably somewhat deprecated by now.
It seems that any of these parsers is likely to provide better results parsing
the datetime fields even for broken clients - which as long as we remain
realistic we know we will run into in the future, as well - than a very narrow
Those can still be used for cases where no other option exists, and such
clients can hope that every client connected to this setup is fully compliant.
But as this is a diverse ecosystem, I'd like to build in as much robustness
and fault tolerance as we can, because my experience tells me that
imperfections are just a normal part of technology, especially when it is
evolving, like Kolab is.
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