Why and when storing local time? (Re: Basic rationale of the KEP #2 design)

[Jeroen van Meeuwen (Kolab Systems)]

Bernhard Reiter wrote:
> Jeroen,
> 
> Am Montag, 21. März 2011 15:41:53 schrieb Jeroen van Meeuwen (Kolab 
Systems):
> > The notation would be Zulu (strict writing). I recommend parsers are
> > being (strongly) recommended to be able to parse any RFC 3339 compatible
> > notation - though always UTC (loose parsing).
> 
> you seem to propose something very similiar to what I have proposed.
> The only difference I can see is that I would leave out the "Z"
> which would still be ISO 8601 compliant and make it localtime.
> Leaving out the "Z" would remove the chance of people interpreting this
> as an UTC value.
> 

Which is not similar to what I am proposing, as it is our own unique format.

> > To indicate the UTC timestamp is to be interpreted (by the parser, not
> > the human) different, and thus likely to have to be presented different,
> > the 'tz' attribute can be used. This would apply to 1) recurring events,
> > 2) events in the future (insert the argument on DST predictability).
> 
> See my other post about why I currently believe that saving Localtime +
> TZ-ID will be better than UTC + TZ-ID. Do you share the argument?
> 

Only in part, as timezone changes (not the same as DST changes) currently seem 
to happen only in Indiana, but even in these cases its counties switch between 
two existing timezones -that's like a traveler, and means -in any case- the 
TZ-ID or datetime would have to be updated for all events regardless.

In this day and age, it's considered too intrusive to global trades and 
economics to change the very definition of a timezone. Hence the controversy 
of counties in Indiana changing timezones.

Additionally, these (sorts of) timezone changes for a geographical location 
are known in tzdata for a good part of the future, so the client can correct 
this if needed.

Furthermore, it breaks compatibility with existing clients. I'm all for taking 
a step back in order to (be able to) move forward, but this is quite serious a 
problem and it seems to have been shoved aside as an acceptable downside.

I don't think it is necessary to break compatibility for the use-case we find 
ourselves trying to solve a problem for.

> > Without UTC datetimes, if specified to need to conform to RFC 3339
> > notation formats, programs cannot use any system library functions to
> > get the raw data out, because an ambiguous -if not false and/or invalid-
> > offset may be included in the raw data, negating the value of the data
> > that is obtained through such functions.
> 
> My proposal would be fine to use an existing datetime parser which most of
> the time is more ISO 8601 compliant than strict rfc3339 compliant.
> (I mean that I can probably find rfc3339 compliant string that break the
> parser, but the subset I've proposed is more save for the parser, though
> not rfc3339 compliant.)
> 

I think you're mistaken in the perception that:

  20110322T220000

to indicate a local time with is somehow ISO-8601 compliant. Sure it is 
compatible with a selected paragraph, but ISO-8601 specifically refers to 
either UTC *or* local time plus the UTC offset, whenever the time is included 
in the datetime (or in cases the offset is unknown, "-00:00" as the offset).

I recon notation formats compatible with ISO-8601 are, not unlike RFC 3339, 
have:

  20110322T220000Z,

  20110322T230000+0100,

  20110322T230000-0000

I recon the specification would explicitly break the standard(s) by removing 
the required timezone indicator or offset, placing it outside the datetime.

  http://www.w3.org/TR/xmlschema-2/#dateTime

It can only add to the confusion, especially in cases where "old" (read: 
current) clients remove the tzid attribute from the data and interpret the 
local time to be UTC -and write it out as such.

> > Without UTC datetimes, if specified to not need to conform to any
> > existing specification -let alone approved in the Internet Society- we
> > have to invent our own datetime notation format unlikely to find
> > adoption beyond Kolab XML parsers, likely hindering further adoption of
> > application compatibility with the Kolab Format, definitely hindering
> > the Kolab Format from ever becoming a widely accepted, standard
> > Groupware Format.
> 
> I do not see that danger, many internetprotocols use other subsets of ISO
> 8601 and rfc3339 is specifically not for dealing with date that need
> precise timezone information. And our format is more easy it can very
> easily precisely defined on the basis of RFC3339 as a variant and is ISO
> 8601 compliant.
> 

That doesn't parse, I'm sorry.

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/format/attachments/20110322/79eae2e5/attachment.html>