KEP2: Modification of datetime type, introduction of 'tz' sub-tag
Georg C. F. Greve
greve at kolabsys.com
Mon Dec 20 12:40:09 CET 2010
Good to hear that you also see the issue.
Let's see whether we can find agreement on how to resolve it.
On Monday 20 December 2010 11.11:33 Hendrik Helwich wrote:
> i think it is not nice to store a wrong UTC time half the year.
I'm not sure that it's wrong to store correct UTC for a location based on that
location's standard time. This is its correct time zone, after all, to which
DST is a temporary and flexible deviation.
> Also technically it is possible that the standard time changes for a time
> zone. This would break the hole concept. I am not sure if this could happen
> in practice but from the format it is possible.
Well, I presume it is theoretically possible that a location would change its
time zone altogether. But then I don't see this realisticially happening for
any other reason than some micro-dictatorship going nuts and wanting some
other time zone than its hated neighbours.
And I dare say that groupware is going to be the least of that countrys
issues, considering the level of disruption this kind of time zone change
would cause on all levels.
But even so, this change in time zone would then also reflect itself in the
Olson database, which also stores the standard time offset to UTC at any given
point in time, so the proposed solution *is* robust even against this case.
> So if already a wrong UTC time is stored half the year it could also be
> stored wrong for the hole year by storing directly the local time as UTC.
> This will be less error-prone.
There is no such thing as storing "local time as UTC".
There is UTC, and then there is local time. The two have an ambiguous
relationship. You'll need to resolve that relationship either way.
Whether you take UTC or local time as your starting point, the complexity of
the problem and the corresponding calculations always remains the same.
There are really only three options that I consider realistic:
(a) store UTC from standard time
(b) store UTC from local time + flag "fromDST"
(c) store local time
Of these, (a) and (c) have the same level of complexity, whereas (b) adds one
layer of complexity, and thus should be discarded immediately.
In comparison between (a) and (c) I think (a) is clearly the winner, because
it ensures that events are tied closely to UTC, and thus timestamps can be
compared without conversion. Otherwise you would always have to convert first
and then compare, which would affect for instance free/busy list creation.
> But IMO it would be much nicer to store local times in a different format
> than UTC e.g. by dismissing the trailing 'Z' character.
This creates a fourth option
(d) create new, standards-incompatible time format to store local time
which has the same issues as (c), and creates additional error potential
because it looks a lot like RFC3339, but it isn't. So clients are likely to
interpret this as UTC, when it is not. So of all the possible solutions, this
would be my least favorite and the most error prone.
> The syntax of the datetime should match the needs of the Kolab XML. If the
> RFC3339 syntax does not match to that need it should be adapted in that case
> IMO. RFC3339 seems not to be intended to store local times with it.
RFC3339 is a subset of ISO8601 for UTC based time storage.
If we wanted to go for local time, which I don't think we should do, we should
then use the standard for this purpose, which would be ISO 8601.
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