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

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

Best regards,

Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110401/16f84a8f/attachment.sig>

More information about the format mailing list