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


Bernhard,

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).


Cheers
	Florian




More information about the format mailing list