KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
h.helwich at tarent.de
Mon Nov 22 16:54:06 CET 2010
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
> > ALL: Who can answer for the other clients?
> > Best regards,
> > Georg
> Kolab-format mailing list
> Kolab-format at kolab.org
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
More information about the format