Basic rationale of the KEP #2 design
Georg C. F. Greve
greve at kolabsys.com
Tue Mar 15 10:00:03 CET 2011
Dear Jeroen,
While I think your points on RFC3339 are valid, as stated before, Hendrik has
a point when it comes to local time storage.
On Monday 14 March 2011 23.04:51 Jeroen van Meeuwen (Kolab Systems) wrote:
> You stated there is no way to restore the originally intended local time
> when UTC datetimes are used, but it seems the last-modification datetime
> has been overlooked.
No, because the last-modification contains only the last modification date.
It is therefore not a source of information for whether the client that wrote
the initial target time for the appointment assumed that that particular
future time would be within DST or not.
The last-modification date only speaks about the current time, and may not even
have been written by the client initially writing the appointment, as another
client may have modified the event subsequently (e.g. the participants, or
exceptions to recurrence).
> You stated clients cannot foretell the future, but back in those days of
> the discussion, where the 'tz' attribute was only supposed to indicate
> the authoritative timezone that should be used, a timestamp for 18:00 UTC
> with a 'tz' attribute set to Europe/Berlin had been consistently saying
> the same thing at the data storage level
It may look the same at a storage level, but may represent both
19:00 in Europe/Berlin
20:00 in Europe/Berlin
in a user's intention. Without knowing whether the client that wrote this
appoinment predicted DST to be in effect for the first occurence of this event,
that is impossible to determine.
> A very simple fix would have been to specify clients must
> write out the datetime as if DST was never invented, and only use their
> baseline offset; two situations for writing the data out exist:
I also thought at some point this might resolve the situation, and I believe
there even was a version of the KEP that attempted it.
The problem is that it irrevocably falsifies the entries.
10:00 in Berlin in the summer is 08:00 UTC, not 09:00 UTC, as would be written
out if following the logic proposed above. Comparisons of entries based on UTC
would therefore become impossible, because one would necessarily have to first
translate into local time, and back into "real UTC" to know how they actually
relate to each other.
Such storage, while also being RFC3339 incompliant because it does not
actually map to UTC directly, does not seem an improvement over storing local
time directly.
For some other entries, e.g. last-modified, such a falsification of the datetime
field would likely throw off a substantial number of clients which are unlikely
to care for the time zone of this field, and just want to use it to sort
through entries by order of last modification, for instance.
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/20110315/d709ef76/attachment.sig>
More information about the format
mailing list