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

[Christian Hilberg]

Hi everyone,

On Friday 19 November 2010 Georg C. F. Greve wrote:
> Hi all,
> 
> Thank you very much for the extremely good input!

There's more to come. :-)

> [...]
> *RFC3339*
> [...] 

Reading through the KEP2 discussions (as much as time permits), it appears
to me that not every argument has been considered with equal weight. I would
very much like to see the Kolab format succeed and the next release of the
format spec to be a good and solid successor to the present one, which, though
it has it's limitations, has proven it's ground to day.

Far from being a datetime pro, I would nevertheless like to stress some
considerations we had in the evolution-kolab plugin team when it comes to
the datetime parts of the upcoming Kolab format spec (though the discussion
is lengthy already, but we surely want to find the best compromise we can):

As SyncKolab relies on an own implementation of the
datetime-normalization (see [1]), the assumption that most Kolab clients
utilize an external library for normalizing datetimes simply does not hold
true. According to Hendrik, Syncphony and evolution-kolab do that
internally and as Gunnar stated Horde does so as well.
It appears that only Kontact uses an external library, i.e. a single one
among multiple FLOSS Kolab clients.

So, fundamentally changing the datetime-format from a unique, concise format
(Zulu times, as of Kolab-Format specification v2.0) to all the different
variants RFC3339 allows for, has at least the following drawbacks:

1. A single, clear definition of the datetime format is exchanged for a
variety of allowed formats (as of RFC3339).
2. The multitude of variants to express datetime per RFC3339 also bears a
large risk of misinterpretations, both technically and logically.
One example of a logical misinterpretation is to think of the possible
offset as a time-zone, as already happened on this list.
3. The assumption that available external libraries which would be used
by the Kolab clients (you cannot expect all the clients to settle on
a single implementation of RFC3339) will implement RFC3339 in a congruent
manner stands on brittle ground, as we know by experience. This means there
is just another layer of datetime interpretation between the Kolab format and
the user of a Kolab client.
4. Most (i.e. all, but one) FLOSS Kolab clients have to be changed
significantly in order to utilize an external library for
datetime-normalization.

I believe this impact is by no means justified, just to accommodate a
single broken Kolab client (which appears to be Kontact as shipped with KDE
SC 4.5, according to Jeroen).
The aforementioned fuzzy point by Georg, that in future utilizing
RFC3339-format may ease interfacing for other tools to Kolab is quite
unspecific and moot anyway, as these tools simply can and should convert
their datetimes to strict Zulu-format before handing over their data to
Kolab, with the help of a RFC3339-library if they so insist.  Forcing existing
Kolab clients to change now in order to accommodate potential, unknown
tools which in future may want to interface with Kolab appears to be
grossly premature.
Furthermore, by experience a specification must be kept concisely defined,
otherwise it will bloat and thus deteriorate over time. Adapting a
specification to accommodate implementations which did not fully adhere
its original normative is definitely taking the route of deterioration.

There is a bit of wisdom which no system architect should easily dismiss
without a second thought:

"Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away."
    -- Antoine de Saint-Exupery


Best regards,

	Christian


[1]
<http://www.mozdev.org/source/browse/synckolab/src/chrome/content/synckolab/tools/text.js?rev=1.11;content-type=text%2Fplain>,
functions string2DateTime and string2CalDateTime

-- 
kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101207/367fe731/attachment.sig>