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

[Georg C. F. Greve]

Hi Hendrik,

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
> specification.

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:

	* Kontact
	* Horde
	* Z-Push
	* Evolution
	* Syncphony
	* Synckolab
	* Toltec
	* Konsek
	* 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?

Best regards,
Georg


-- 
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/20101122/63cd965c/attachment.sig>