Why and when storing local time?

[Florian v. Samson]

Bernhard,

Am Dienstag, 22. März 2011 um 14:13:52 schrieb Bernhard Reiter:
> Am Freitag, 18. März 2011 17:39:48 schrieb Florian v. Samson:
> > > So let me use the
> > > opportuniy to explain why I believe that we should store the local
> > > time plus tz id of datetimes in the future, in particular
> > > for start and stop datetimes of events and tasks:
> > >
> > > i) The transformation of UTC <---> Local Time of tz=L is not yet
> > > fully determined for the future. For the past it is fixed as the
> > > definition of L is done. For the future it could change.
> > >
> > > ii) I do assume that most of the time a user will think about an
> > > event in Local Time tz=L when she creates it. And whatever happens to
> > > the definition of L in the future, the event should stay there.
> >
> > I agree to both requirements, which can be fulfilled by UTC + TZ-ID
> > *and* LocalTime + TZ-ID as well.
>
> An example: As a user I want 10:00 in Winter Berlin/Time, which TZ-data
> is UTC+1 at the time I create the event for the date I am creating it.
>
> Saving 1) UTC + TZ-ID: "9:00 + Europe/Berlin"
>        2) Localtime + TZ-ID: "10:00 + Europe/Berlin"
>
> Now TZ-data for Berlin changes to UTC+2 for that date.
> Variant 2) still works, I am still at 10:00 in Berlin as ii) demands.
> But for 1), if I just apply the new TZ-data, I end up with 11:00 Berlin.

... which is wrong, as you incorrectly "just applied" the TZ-data_new to the 
UTC-datetime_old, which cannot work.  I already pointed out the necessity 
to: 
a. Calculate the users intent (local time) from UTC-datetime_old and 
TZ-data_old
b. Use the TZ-data_new to calculate UTC-datetime_new from the users intent 
(local time)
c. Store UTC-datetime_new and TZ-data_new in the Kolab-object

> (To discuss this in more detail:
> It is important to note that we are still at the same date, it is _not_
> the creation date of the appointment. To be able to reconstruct the users
> wish from 1) I would need to have the historic info what the old TZ-data
> at creation date in the creating client thought about the date of the
> event. 

Yes.

> This would be possible when introducing to keep a record of all 
> old relevant tz-data around.)

No, I do not think so: keeping the TZ-data which has been used for 
calculating the UTC-datetime is sufficient; this is always the recent 
TZ-data, until it becomes superseded by newer TZ-data which triggers an 
update of the Kolab-object, hence it is the recent TZ-data (with correct 
UTC-datetimes) again.

> > For UTC + TZ-ID to fulfil the requirements i) and ii), in-format
> > TZ-data has to be used and the client updating this TZ-data in the
> > Kolab-object is responsible to adjust (i.e. either alter or split) the
> > event according to a set of rules we would have to specify.
>
> So you are using the old tz-data in-the object to calculate the time the
> user wanted and to adjust the saveing of 1) to "8:00 + Europe/Berlin".

Yes.

> Which leads to the discussion of where to save the TZ-data, within each
> object or to keep it in a database external to the object.

I believe when storing datetimes in UTC, in-format TZ-data makes most sense, 
as without it, UTC-datetimes seem to be infeasible.

> Note that it would be data for several TZ-IDs as startdate and enddate
> could have use different timezones.

This is a really rare case, IMO, and these are at most two (not "several"), 
AFAICS.

> I suggest we take this to a different thread.
>
> > > iv) I agree that using the Local Time tz=L variant should only be
> > > recommended for datetimes in the future, where the transformation
> > > really matters.
> >
> > Ugh, I was reluctant to propose above due to its complexity, but
> > proposing a wild mix of UTC and LocalTime date-times sounds pretty
> > complex and error-prone as well.
>
> To me UTC is a subset of Localtime, as UTC can be chosen as timezone.

This is not what we were discussing, IMO.  
But as an unrelated note, this is definitely correct: UTC has to be timezone 
the user can choose from, as any other timezone.

The question discussed is, what we chose as reference points for datetime 
calculations in the Kolab-format specification.

> As for the format, UTC would be possible for all datetime and
> for future datetime tags, which we can precisly name, localtime is a
> SHOULD. Interface would need to offer such settings anyway.

Ugh, I have trouble parsing this paragraph, especially the last sentence, 
where I am missing the references: which "interface", what "such settings" 
and why "anyway"?

> In addition all objects without such datetime tags could still be written
> in the old format. I am not sure I understand where you see the
> complexity and source for error.

Designing this is mind-boggling enough, but I think as we are about to 
master the complexity of the whole topic, we probably can properly design 
and specify datetimes with varying reference times, too.  
But imagine the poor programmer implementing this, who did not dive into 
that topic for months, already: dealing with and converting datetimes with 
two or three different reference times (e.g. Localtime, UTC; or UTC-old, 
UTC-new, Localtime, when there is a change in TZ-data) can lead to utter 
confusion (and hence ultimately wrong implementations).  Although with a 
clear set of rules, checks and balances, and (if needed) well defined 
transitions between different reference times, we may provide sufficient 
help.

Cheers
	Florian