localtime +tz-id how to store
Georg C. F. Greve
greve at kolabsys.com
Fri Apr 1 17:03:13 CEST 2011
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
> 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.
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