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

Hendrik Helwich h.helwich at
Tue Dec 14 11:03:23 CET 2010

Hi Georg,

Am Freitag, 10. Dezember 2010 15:09:04 schrieb Georg C. F. Greve:
> Hi Hendrik,
> Allow me a quick comment on two general points:
> Firstly, the Kolab Groupware Solution consists of various components on the
> server as well as the various clients. In order to form a consistent user
> experience, the architecture needs to be consistent overall, which means
> there will be implications for client-side architecture from the overall
> picture, sometimes down to the level of user-interaction.
> This is what the documentation should ensure. We know it did so imperfectly
> in the past, and you seemed to welcome [1] more comprehensive documentation
> before. To me this still seems like the right approach, but it necessarily
> means decisions will be made that have some bearing on client architecture.
> Secondly, it seems more sensible to discuss the current draft of a document
> instead of what has already been deprecated and exists primarily for
> historical record.
> So I'll respond to your issues as far as they pertain to the current draft.
> The primary issue for you now seems to be that clients ought to be able to
> parse RFC3339, which is something that was introduced in part also because
> I remembered you making the point several times that clients ought to be
> liberal when reading datetime strings.

for the current Kolab format 1.0 i would say it is necessary to be able to 
parse RFC3339 datetimes to not lock out kolab clients which are not conform 
with the specification. It is certainly a good idea to use a RFC3339 library 

But for the Kolab format 1.1 we have the chance to be more strict in the 
definition and the parsing of the Kolab format.
The KEP2 document says that the datetime types *must* be written in the Zulu 
Why should clients than be forced to use a RFC3339 library if it is not needed 
and the use of a system library would also be possible?

Also the problem that we have right now with the datetime type, results from 
the fact that some Kolab clients are using a RFC3339 library in a way that 
breaks the Kolab 1.0 format.
So it is rather a disadvantage in a kolab client implementation to use a 
RFC3339 library if it is not needed and it should not be constrained in the 
specification in my opinion.

Also i think the specification should concentrate on the format constraints 
and should not make implementation constraints if they are not needed.
The specification should also be clear without ambiguity and i think the first 
three bullet points in KEP 2 should be made clearer.

Also i am not sure if i understand the 4th bullet point:

"All such timestamps MUST be calculated against *Standard Time*, NOT in 
Daylight Saving Time (DST). "

IMO the datetimes should be stored in the UTC time zone like in the Koab 1.0 
format. Local times would also be ok if a timezone is attached but then the 
time zone information with the offsets of the standard time and the DST will 
be stored somewhere else (probably outside the kolab format). Or what exactly 
is meant with "calculated" here?

> In fact you said before RFC3339 reading was explicitly okay, but that you
> wanted the strings to be written strictly Zulu. [2] Because you were
> feeling so strongly about this, the latest draft specifies exactly that
> strict writing of datetime objects in Zulu time.
> The other issue appears to be about how to formulate where such strict
> writing should take place. I'm fine with your proposal of saying in KEP2
> that this should be done for all objects.
> When we introduce new object types, this will be a sane default, and one
> that we can discuss deviating from if and when it makes sense, e.g. an
> object requiring the higher precision.

Thats a good idea IMO.

Best regards,


> Best regards,
> Georg
> [1]
> [2]

More information about the format mailing list