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

Bernhard Reiter bernhard at intevation.de
Tue Mar 22 17:43:53 CET 2011


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.

> 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?

> 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.)

> 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.


Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110322/e72f3dfe/attachment.sig>

More information about the format mailing list