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

Hendrik Helwich h.helwich at
Mon Nov 22 12:08:22 CET 2010

Hi Georg,

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
> point.
> 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,


> Best regards,
> Georg

More information about the format mailing list