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

[Hendrik Helwich]

Am Dienstag, 23. November 2010 14:49:57 schrieb Jeroen van Meeuwen (Kolab 
Systems):
> On Tuesday, November 23, 2010 12:10:11 pm Hendrik Helwich wrote:
> > 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.
>
> Alright.
>
> I can describe a UTC datetime in many notation formats. To illustrate:
>
>   23-11-2010 13:00 UTC  vs.  11-23-2010 13:00 UTC
>
> Notice how the date is different (DD-MM vs. MM-DD).
>
> RFC 3339 standardizes the *notation* of date time. For example, it
> describes that it should order from least precise to most precise, or Year,
> Month, Day, Hour, Minute, Second, Millisecond (Section 5.1 and 5.2).
>
> The *notation* used is something completely different from what the Kolab
> format expects the datetime to describe no matter what the notation. While
> the RFC3339 allows the *notation* to specify an offset, the Kolab XML
> standard would require such offset to always be set to 0.
>
> In other words, when a client wants to write a datetime 13:00 UTC+1, it can
> do so in the following notations:
>
> - "2010-01-01T12:00:00Z", or
>
> - "2010-01-01 12:00:00 +0000"

Hi Jeroen,

now i understand the point.
But would this date be allowed to stored in a kolab datetime value?:

2009-07-27T08:11:32.525+02:00

This is a value we definitely had in practice (but i don't know from which 
client). 
Or will the above value without milliseconds be allowed?:

2009-07-27T08:11:32+02:00

Th last one can be converted to UTC with no problem.
The first one needs to be rounded in some way.


> however, it must always be the UTC equivalent of such time a client wants
> to describe. We're back to the discussion on recurrence and DST changes to
> determine *why* the Kolab XML must always have UTC be used -it's mainly
> because UTC is the only universal time and never changes wrt. DST or offset
> changes around the world.
>
> > 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 implementation.
>
> We see different clients -outside of the specification- use different
> notations for the datetime already. So, in order to touch up our definition
> of the exact notation of the datetime, it would be easier for us to
> describe clients must be compatible with reading and writing RFC 3339
> compatible notations (which a client most likely needs to be able to read
> and write anyways), then it is for us to lock down the specification to the
> zulu notation like we do now -adding additional effort on a client's Kolab
> XML compatibility as Kolab XML is the excemption to the rule, adding
> additional confusion (apparently), and overall making Kolab XML, Kolab
> Groupware and clients more prone to error.

i still like storing the strict Zulu format more, because you only have one 
way to store a datetime UTC value and not many possibilities. This is so easy 
to read and write and there is not much place for confusion.
But this point already seems to be decided and i also understand the pros of 
changing the spec at this point.

Best regards

Hendrik

> Kind regards,
>
> Jeroen van Meeuwen