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

[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"

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.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20101123/434f53e7/attachment.html>