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

Georg C. F. Greve greve at kolabsys.com
Fri Dec 10 15:09:04 CET 2010


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.

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.

Best regards,
Georg



[1] http://kolab.org/pipermail/kolab-format/2010-November/001080.html
[2] http://kolab.org/pipermail/kolab-format/2010-November/001072.html

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

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: <http://lists.kolab.org/pipermail/format/attachments/20101210/cda5e08a/attachment.sig>


More information about the format mailing list