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

[Georg C. F. Greve]

Hi Christian,

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 [1].

The same would be true for PHP5, for instance, e.g this older article, [2] 
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 
simple parser.

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.

Best regards,
Georg


[1] 
http://download.oracle.com/javase/6/docs/api/index.html?java/text/SimpleDateFormat.html
[2] http://laughingmeme.org/2007/02/27/looking-at-php5s-datetime-and-
datetimezone/

-- 
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/20101207/7ed6b701/attachment.sig>