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

[Jeroen van Meeuwen (Kolab Systems)]

On Tuesday, November 23, 2010 03:15:26 pm Hendrik Helwich wrote:
> 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.
> 

The problem as I see it, lays in the +02:00 part. The milliseconds... are RFC 
3339 compliant and should thus be allowed, in my opinion (but they are not in 
the current Kolab XML standard).

I'm saying that the "+0200" is a problem, because the number is subject to 
local UTC offset changes, such as is the case with DST. There is virtually no 
way "+0200" can be reliably resolved to the indended UTC datetime, as we have 
no indication of the authoritative location for which the +0200 was originally 
intended; and thus also no rules we can use on UTC offset changes.

Hence, the proposal would introduce an Olson database location entry, from 
which we can always calculate the intended offset; for millennia to come, 
hopefully.

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/f98fcbf0/attachment.html>