[Kolab-devel] KEP 2: Modification of datetime type, introduction of 'tz' sub-tag

[Hendrik Helwich]

Hello,

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 
zone database

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 
similar opinions.

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.

Best regards

Hendrik