localtime +tz-id how to store (Re: A summary of sorts (was: Re: Why and when storing local time?))

[Bernhard Reiter]

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)
b) http://kolab.org/pipermail/kolab-format/2011-March/001237.html

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

Example: 
<start-date tz="Europe/Brussels">2001-06-19t11:01:23+02:00</start-date>

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.

Example: 
<start-date tz="Europe/Brussels">2001-06-19T11:01:23</start-date>


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.

Discussion
==========

> 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...
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/20110401/740a0717/attachment.sig>