Why and when storing local time? (Re: Basic rationale of the KEP #2 design)
Florian v. Samson
florian.samson at bsi.bund.de
Mon Apr 4 12:15:40 CEST 2011
Am Freitag, 1. April 2011 um 10:44:49 schrieb Bernhard Reiter:
> My example was designed to show that if you save data as UTC
> you need to have the precise tz-data available for when it was written.
> In order to do the calculation you would need to have available
> * tz-data when writing the object, let's call it tz-data-old
> * the updated tz-data, let's call it tz-data-new
Yes, but IMO only a single set of TZ-data (for the sole TZ of the event)
should and must be stored in an Kolab-object.
The steps would be:
1. A Kolab-client deals with an Kolab-object and realises that the
Kolab-object's TZ-data is older than another available source of TZ-data
(local zoneinfo-database, a zoneinfo web-service, whatever).
2. If the Kolab-Client has write-access to that object's IMAP-directory, it
updates the TZ-data and eventually adjusts / splits date-time fields.
> So saving data as UTC will mean you need to indicate tz-data-old
> in the object somehow, either as number or having it in there in total.
> You must update that indicator to profit from tz-data-new.
> Thus it forces an object rewrite.
Yes, true, I never denied that drawback, although I do disagree that it
ultimately "forces" an object rewrite immediately: If (for some reason) the
object is not rewritten by the first client which detects that the
in-format TZ-data has become stale, the same situation can detected and
resolved later in exactly the same manner. Meanwhile all read-only clients
display exactly what they displayed before: the times according to old the
TZ-data. As changes in TZ-data are known usually years ahead (at least
many, many months ahead) updating the Kolab-objects can happen in a rather
lazy, delayed manner, as only time-dates in the far future will "jump".
But for sure a Kolab-object with stale TZ-data should be updated sooner or
later, thus causing an object rewrite.
> Which brings us to again to
> b) Pros and cons of re-writing the objects when tz-data changes.
Yes (this is the topic where I seem to have missed a mail from you).
More information about the format