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

[Hendrik Helwich]

Am Montag, 22. November 2010 16:50:20 schrieb 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

sorry i pressed some key in kontact and the mail got send away :-)

i wanted to say that i dont think it is a good way to adapt the specification 
if some clients do not stick to it.
There should be some reference like a specification or a test suite or a 
refence implementation library. Otherwise it is very difficult for developers 
who want to code a kolab client.

Best regards

Hendrik


> Best regards
>
> Hendrik
>
> > ALL: Who can answer for the other clients?
> >
> > Best regards,
> > Georg
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format


-- 
tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH
Geschäftsführer: Boris Esser, Elmar Geese
HRB AG Bonn 5168 - USt-ID (VAT): DE122264941

Heilsbachstraße 24,  53123 Bonn,   Telefon: +49 228 52675-0
Thiemannstraße 36 a, 12059 Berlin, Telefon: +49 30 5682943-30
Internet: http://www.tarent.de/  • Telefax: +49 228 52675-25