KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
bernhard at intevation.de
Thu Nov 18 21:56:06 CET 2010
On Wednesday 17 November 2010 17:10:56 Georg C. F. Greve wrote:
> On Wednesday 17 November 2010 16.32:58 Hendrik Helwich wrote:
> > Why not keep the established UTC time format like it is defined in the
> > kolab specification? It holds all needed information and it would not be
> > necessary to adapt the kolab specification on that point.
> As you correctly pointed out, the specification is inconsistent in this
Which client and version did you test that gave the "+00:00" format
(which I also believe is wrong according to the spec)?
Note that Kontact Proko2 is the reference client and Kontact e35 is coming
very close. Kontact from PIM 4.x something probably has more defects,
so it will be less compatible.
> So right now the text says one thing, the equally authoritative clients
> referred to in the document do something else, and apparently use just the
> function based on RFC3339.
> So sticking with the RFC means less code changed:
> What old clients write is perfectly RFC compatible, and clients should not
> implement their own parsers for this, but use the system function, which
> also implements the RFC.
I'd rather would like to stick with the variant that uses only one
string version and not full RFC3339.
(I agree that it is a strong argument if we found a major issue in the
Managing Director - Owner: www.intevation.net (Free Software Company)
Deputy Germany Coordinator: fsfeurope.org. Coordinator: Kolab-Konsortium.com.
Intevation GmbH, Neuer Graben 17, Osnabrück, DE; AG Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the format