localtime +tz-id how to store
Georg C. F. Greve
greve at kolabsys.com
Fri Apr 1 14:23:56 CEST 2011
On Friday 01 April 2011 12.50:40 Bernhard Reiter wrote:
> For the datetime stamps in the past and present, we do not need to store
> localtime + tz-id at all.
That is why these fields do not require TZ-ID. From the KEP:
* All datetime storage fields MAY carry up to one 'tz' attribute describing
the time zone in the uniform naming convention designed by Paul Eggert,
specifying time zones from the Olson database, a.k.a. tz database, a.k.a.
* All fields that store future dates at the time of writing an entry, e.g.
the 'start-date' and 'end-date' fields, MUST define the 'tz' attribute. Where
the event should be calculated strictly against UTC, emulating previous
behaviour, the value of the 'tz' field must be set to 'UTC' (all caps)
> As appointment start and end times are usually in the future, we use it
> there always. As for creation-date, we use UTC only.
> At least this sound sensible to me.
That establishes two different storage formats for datetime, which thus far
most people considered a recipe for trouble.
It complicates the KEP, requires additional client side logic, and possibly
even maintaining two parsers instead of one, especially if we do not mandate
RFC3339 encoding for the time zone sensitive datetime fields.
The sole gain would be a few bytes saved in storage.
So it does not seem overly sensible to me.
> In the case of non-UTC data, with the current status of the KEP,
> all clients will a have to do the extra implementation steps
> to conform with the KEP. You could change the KEP to say
> that only tags, X, Y, Z, you need to follow the tz-id preferance
> or only in some other cases. But as it stands now, those partial clients
> cannot be sure of the offset to be correct.
No actually, because (a) there is no need to write TZ-ID for those fields, but
(b) even if clients did write it with TZ attribute, which they MAY do, the
other writing requirements are sufficiently strong so the client may just ignore
the tz attribute and will obtain a sane result.
> rfc3339 + tz-id is something new for many arguments you have presented.
This does not parse. RFC3339 storage is old, and plenty of libraries and
functions exist for it, so it is clearly not new in the cases where clients
can just ignore the TZ attribute.
> My proposal is iso compliant.
Only where the entire environment is restricted to one single local time zone.
But that is not a reasonable restriction for Kolab.
If you want ISO8601 compliant timezone robust times, you need to include time
zone information / offsets according to ISO8601, which brings you back to
RFC3339 if you choose the simplest approach to do so.
But compliance was not the issue.
The ability of clients, scripts and other tools to use this data without a
strict requirement for a time zone data lookup was.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format