Why and when storing local time?

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

(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.
This would be possible when introducing to keep a record of all old relevant 
tz-data around.)

> 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".
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.
Note that it would be data for several TZ-IDs as startdate and enddate
could have use different timezones.

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.
As for the format, UTC would be possibly 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.
In addtion 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.

Bernhard


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110322/5b6c7a7b/attachment.sig>