KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
Georg C. F. Greve
greve at kolabsys.com
Mon Nov 22 15:59:06 CET 2010
On Monday 22 November 2010 12.08:22 Hendrik Helwich wrote:
> i understand that this is not wanted, but it should also be possible with
> that RFC3339 library to store only in the UTC form. This would not be much
> trouble in coding (if it is not already done like this) and will fit the
Yes. And clients can of course choose to continue to do that.
> If all RFC3339 formats are accepted when reading the kolab
> xml this is also no problem because the kolab xml parsing should already
> be not to strict because the specification is interpreted in a loose way
> by the different clients which write the format.
Exactly. But right now it does not say that clients need to be able to
understand RFC3339, although they seem to be doing so already.
Which is why it was proposed to make that explicit.
> There are also system functions which read the simple UTC format.
Do we know whether any clients use those?
The clients I am aware of that are actively used are:
* Bynari Insight
of which some share code (e.g. Z-Push and Horde both use Kolab_Format IIRC).
What do the others use?
If we find out that people already use the RFC3339 capable parsers, I think it
would make sense to agree to the common baseline that most applications use
for this purpose, which is RFC3339 - because that code is more likely to be
used by many others, thus likely being more robust than any (now likely
deprecated) code for other formats.
Questions to all client implementors therefore would be:
(a) Do you use your own parser for datetime stamps?
(a1) If so: Why?
(b) Does the parser you use support RFC3339 datetime stamps?
Hendrik: Can you answer these for the Evolution connector and Syncphony?
ALL: Who can answer for the other clients?
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format