[Kolab-devel] KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Tue Nov 23 14:49:57 CET 2010
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.
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.
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the format