KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
h.helwich at tarent.de
Mon Nov 22 12:08:22 CET 2010
Am Mittwoch, 17. November 2010 17:10:56 schrieb Georg C. F. Greve:
> 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
> 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:
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. 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.
> 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.
There are also system functions which read the simple UTC format.
I think it is not nice to have the possibilities to define the same
information in many ways, if there is no benefit from it. This is a potential
error source i think.
> Best regards,
More information about the format