[Kolab-devel] KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
h.helwich at tarent.de
Mon Nov 29 11:00:41 CET 2010
I think there was no consent reached in the discussion regarding the two
central points of what finally became the KEP 2 draft:
1) strict Zulu UTC Format versus RFC3339 datetime format in the Kolab format
2) storing DST information in the Kolab format versus using an external time
We discussed these two issues thoroughly at one project teleconference with
all project team members and we came to the conclusion that the strict Zulu
UTC format and the integration of the DST information in the Kolab format
will be a superior solution for addressing the issues of the missing time
zone information in the Kolab format.
I think the majority of people here on this mailing list have expressed
Anyway, the discussion seems to have stopped and I would like to encourage
everyone on this list to get involved in this discussion again and balance
the pros and cons.
Our reasoning is as follows:
We think the strict Zulu UTC format will be a better solution than allowing
all the various RFC3339 possibilities, because it is much simpler, hence far
less error-prone. It is far easier to implement than RFC3339, without the
need to resort to an external library, and has the advantage that not every
Kolab client needs to be adapted. Existing clients can just rely on the Kolab
format specification as is. The RFC3339 time format adds much more complexity
to the Kolab format without adding any significant advantage. It is a great
potential source of errors to switch from an easy, normalized datetime format
to a complex datetime format with a lot of redundancy, resulting in the need
to change the specification and potentially all client implementations which
are relying on any previously published version of the Kolab format.
Also this might create a precedent case in which a Kolab client in some
version (potentially Kontact in KDE 4.5) is writing the Kolab format in a
wrong way and the specification is adapted to fit this bug and then all other
Kolab clients must be adapted to fit the changed specification.
The only argument which supports using the RFC3339 datetime format as far as I
remember was that there is no need to fix a possible bug in a Kolab client in
some specific version. But it is not fully clear which Kolab clients in which
versions write a datetime format differing from the strict Zulu format. As
far as I know most of the clients are doing this correctly. This raises the
question why should not the bugs be fixed in the clients which show faulty
behaviour and stay with the datetime format as it is specified currently?
Regarding the second issue we think that it is better to have a self-contained
Kolab event type than introducing a dependency on an external time zone
database. Time zone information is subject to change, which will result in
unaligned time zone databases. Differing entries on distinct systems
introduce errors in calculation of the local time. Smartphones and embedded
devices may ship with either incomplete or completely without time zone
information and update mechanisms on these devices vary vastly. Including the
time zone information in the Kolab format ensures the same results in the
calculation of local time for all attendees of an appointment, because every
Kolab client will do it's calculations based on the same data set. This
reliability cannot be achieved by utilizing external time zone databases.
Since most people on this list seem to have a similar opinion on these two
issues we would like to propose a change of the KEP 2 document as to (a)
stick with the present Kolab datetime format and (b) include time zone
information directly into the Kolab format.
More information about the format