localtime +tz-id how to store

[Georg C. F. Greve]

On Friday 01 April 2011 15.57:34 Bernhard Reiter wrote:
> > 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.
> 
> Okay, the result will be sane, but might be an hour or more off.
> In cases I want the real time, I still have to implement the extra loop.

No. For past and present datetime fields it will be spot on. 

Only datetime fields in the future require the additional loop of testing 
against the time zone. For all others this is unnecessary additional 
complexity which is forced upon the clients by not using RFC3339. 


> > Only where the entire environment is restricted
> > to one single local time zone.
> 
> No, this is a local time where you have the timezone from the tz-it.

Exactly. So the time stored is totally useless without the TZID. 

When using RFC3339 that is not the case.


> Did you happend to read ISO8601?

Yes, when we were reviewing the ISO 29500 specification.

That has admittedly been a while ago, but the point made does not seem to be 
debated: ISO8601 allows specifying "local time" stamps. But such local time 
objects are a lot less common than RFC3339 from what I can see as their 
usefulness in computer terms is quite limited.

And as they have no inherent orentation/relation to UTC, they are worthless 
without also interpreting the TZID, which adds one more step.

Usage of RFC3339 adds a trivial aspect, namely a "+/-ABCD" offset, which gets 
parsed by the widely spread RFC3339 parsers in a wide variety of libraries and 
programming languages, and delivers sane, useful results for most cases we are 
looking at without that additional step.


> From second hand information my suggestion seems to be iso compliant
> and thus parsers will return a localtime object.

Ah, but for which local time? Most systems will parse such timestamps as local 
to the local system, which is likely to be wrong in the majority of cases for 
groupware objects.


> Using YYYY-MM-DDTHH:MM:SSZ for those tags where client would want simple
> parsing would be even more easy and ISO and rfc3339 compliant.

It makes no difference. The parser will need to parse each datetime field.

So YYYY-MM-DDTHH:MM:SSZ with no TZID attribute is a perfectly fine notation for 
creation date & Co, and the current KEP allows that, as these are not the 
fields that must carry the TZID.

But if a client writes YYYY-MM-DDTHH:MM:SS+NNMM without TZID that is equally 
fine and trivial for a parser that can deal with RFC3339 + TZID attribute. And 
maybe there is a use case why a client would prefer one notation over another. 

And yes, I can see cases where a script would want to use the RFC3339 without 
the TZID information even for future fields. There are cases where a potential 
shift of one hour due to DST changes may very well be acceptable or 
neglegible, e.g. some statistics, sorting of events / cleaning out older 
events, and so on and so forth.

So I don't think we should make such secondary usage harder than it has to be, 
we should avoid unnecessary complications to the rule set, and we should allow 
clients some space for innovation where that freedom does not impede on the 
rest of the solution or other clients.

Best regards,
Georg


-- 
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/788a3da9/attachment.sig>