[Kolab-devel] KEP 2: Modification of datetime type, introduction of 'tz' sub-tag

Hendrik Helwich h.helwich at tarent.de
Tue Nov 23 12:10:11 CET 2010

Am Dienstag, 23. November 2010 11:04:57 schrieb Jeroen van Meeuwen (Kolab 
> On Monday, November 22, 2010 12:08:22 pm Hendrik Helwich wrote:
> > Hi Georg,
> >
> > 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.
> We are talking about two different things here, and I feel they are being
> mixed up; to clarify:
> - The datetime will always be UTC -which is the "payload" if you will,
> - The datetime /format/ is set to Zulu notation now, and the consideration
> is to make that rfc3339 compatible -which is the "notation format", if you
> will.

Hi Jeroen.

sorry, but this did not clarify the things for me :-)
Can you please describe in more detail what you mean?
We were discussing the datetime format in the kolab xml format and if it 
should be in the UTC format like it is described in the kolab specification 
or if it should be possible to store it also in the other forms which are 
allowed by RFC3339.
In both cases this datetime will be converted to a UTC time in a kolab 
implementation i would assume.
So with the RFC3339 it would just be possible to store a UTC datetime in many 
different forms but internally it will always be converted to a UTC datetime.
I think this is because some clients accidentally store a UTC datetime in a 
different style than the UTC format given in the specification but it holds 
the same information and can be converted back to a UTC datetime in an 

Best regards


> Kind regards,
> Jeroen van Meeuwen

More information about the format mailing list