KEP 2: Modification of datetime type, introduction of 'tz' sub-tag

Georg C. F. Greve greve at
Wed Nov 17 12:57:27 CET 2010

On Wednesday 17 November 2010 12.33:58 Jeroen van Meeuwen (Kolab Systems) 
> - Does the nesting make the new version of the format incompatible with
> older  clients?

Provided the clients are Kolab compliant, i.e. preserve unknown tags, and use 
proper XML parsing, it should not be. 

> - Is there a specific reason the <tz /> element is nested in the
> <start-date  /> element? Do we expect to see end-dates specified for a
> different timezone?

Most clients allow to choose the time zone for each of the time fields that is 
entered. So not being able to model that in storage would impose much larger 
changes upon clients in their user interaction, or an implicit decision which 
explicit user input to discard, whereas a nested value will avoid placing that 
burden on the client implementor or user.

At the same time, there is no additional cost to doing this nested, and it 
makes sure that we can cover future use cases that we may not be aware of 
right now without having to modify the format for them.

Best regards,

Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at
t: +41 78 904 43 33

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: <>

More information about the format mailing list