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

[Hendrik Helwich]

Am Montag, 22. November 2010 15:59:06 schrieb 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?

Hi Georg,

Since we took the specification as reference it was first coded to accept the 
dates like described in the specification e.g.:
* 2010-11-22T16:12:11Z

Since we noticed that some clients write their own formats, the parser was 
extended to also accept them e.g.:
* 2009-11-09T10:41:58+00:00
* 2009-07-27T08:11:32.525+02:00

If some clients write the kolab format in a different way (without any good 
reason) than it is described in the specification, i think it is not a good 
way to adapt the specification 
I still do not think that it is a good way to change the specification if some 
clients do their own thing

I think it is for developers who want to implement a kolab client if some 
clients do not 
I still think that the kolab  a main problem with the kolab format is, that 
the specification is not sufficient if you want to implement a kolab client. 
You also have to study the behavior of the other clients and even need to get 
through their code to be able to interoperate with them.
In my opinion the specification should be made more 

Best regards

Hendrik


> ALL: Who can answer for the other clients?
>
> Best regards,
> Georg