localtime +tz-id how to store (Re: A summary of sorts (was: Re: Why and when storing local time?))
bernhard at intevation.de
Fri Apr 1 09:47:38 CEST 2011
Am Donnerstag, 31. März 2011 13:01:32 schrieb Georg C. F. Greve:
> If local time is also stored as RFC3339, it adds a slight redundancy, true.
Let me branch of this thread about discussing in which format we would
save the information of localtime + tz-id. I thought about this some more.
So we talk about two format proposals:
a) KEP2 id=1086 (current draft)
Summary of key features:
a) is "All datetime fields MUST be formatted according to RFC 3339"
and "Where this offset contradicts the 'tz' attribute, the 'tz' attribute MUST
prevail. It is therefore recommended to ignore the offset where a 'tz'
attribute exists and only fall back to it where it does not."
b) take rfc3339 ABNF rules and replace the following rules with
time-secfrac = "." 3DIGIT
time-offset = ["Z"] ; without Z, there is an accompaining tz attribute
And fixed upper case "T" and "Z" where they appear.
Implementation of reading
With a) you cannot give "2001-06-19T11:01:23+02:00" to the iso8661 parser
you have, if you have an tz-id, because it might give you the wrong UTC back.
Thus you will have to cut out "2001-06-19T11:01:23" before you can give it to
the parser. (So the KEP should be changed to a "MUST ignore the offset" when
a tz-id exist.)
For b) you can directly use "2001-06-19T11:01:23".
Implementation of writing
For both you have to transfer the time into the localtime of "Europe/Brussels"
and you have to write out the "Europe/Brussels" string.
For a) if there is no direct rfc3339 writing function available, you will have
to write your own, which means you first have to calculate the UTC
difference, before you can write out the "+02:00" part. This is the case with
Qt, so we have one real world example.
You cannot just write out "-00:00" for an unknown timezone, because you know
the timezone and this would violate the spirit of the rfc.
For b) you write out the local time directly.
> If we invent a new notation for storing local time, that is no longer
> possible as it will need mapping to UTC first.
With the above implementation rules explained, I believe the two example
strings for a) and b) both can be considered to represent a "new" notation
for storing local time. They both cannot be expected to be fully implemented
in an existing parsers and they are ISO 8661 compliant, which mean existing
parser can help a bit in both cases.
The more I think about it, this does not come at surprise as rfc3339
explicitely states to not care about solving the problem of tz-data
change. Search for "daylight" im the rfc.
> To be honest I'm not convinced that avoiding a slight redundancy is worth
> such a complication for scripts and other "partial clients" that may want
> to make some secondary or tertiary use of Kolab data.
I have only checked one example of a real implementation: Qt 4.6.3 and 4.7.2.
If this is roughly similiar to other good system libraries, considering
the above, it looks like variant b) is easier to parse.
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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the format