Why and when storing local time? (Re: Basic rationale of the KEP #2 design)

[Florian v. Samson]

Bernhard,

Am Montag, 28. März 2011 um 14:59:33 schrieb Bernhard Reiter:
> Am Donnerstag, 24. März 2011 12:29:11 schrieb Jeroen van Meeuwen 
> (Kolab Systems):
> > > Your version of using the "baseline" UTC offset only works,
> > > if this part of the tz-data does not change. I was proposing a
> > > solution for a non-daylight saving rule change in the tz-data.

Why do you think that DST-date changes (i.e. the dates of switching from / 
to DST) are different from any other changes in the TZ-data?
I think they are not, technically, they are just more likely to occur.

> Your version would also not solve the problem with changes to the DST
> rules within the tz-data. This is also what Georg tried to explain.

See question above.

> Let me try it again:
>
> As a user I want 15:00 in May 2015 in Berlin.
> I have available the tz-data from Dec 2010 for Berlin,
>   which tells me that for May 2015 it is UTC+2
>   and for Jan 2015 it is UTC+1.
>
> Three possibilities:
>
> Saving 1) UTC + TZ-ID: "13:00 + Europe/Berlin"
>        2) Localtime + TZ-ID: "15:00 + Europe/Berlin"
>        3) Jeroen's baseline + TZ-ID: "14:00 + Europe/Berlin"
>
> In Dez 2012 I get an update of my tz-data for Berlin

Who gets that update?  And how?
Let us assume the local zoneinfo-database ("Olson database") has been 
locally updated on that client computer.

>   and now it tells me that for May 2015 it is UTC+4
>   and still Jan 2015 stays at UTC+1.

Ah, you identified another drawback of PIM-Client external TZ-data, which I 
already mentioned a couple of times: dates displayed may jump any time due 
to such updates of the zoneinfo-data, but at different times for different 
clients, depending on their software configuration (Windows, Linux, FreeBSD 
etc.), update frequency etc.
This "and now it tells you <bullshit>" does not hold true for in-format 
TZ-data, with which an update of this Kolab-object has to happen, altering 
the displayed time in one go for all clients accessing that object.  
This update procedure also prevents clients from displaying a completely 
incorrect time: it is either the old calculation (which has been correct, 
but is not any more), or the new, correct one.  I believe that is a quite 
graceful behaviour and the best we can achieve.

> With variant 2) I can easily get the right UTC which is 11:00
> and then display the appointment in other timezones as I wish,
> so this works.

You can always "display the appointment in other timezones as you wish", as 
soon as you obtained "the right UTC": this is always true for any 
datetime-format.
But also true is, that one can manipulate the local time directly, when 
recorded as local time, saving a one or two additions/substractions which 
might take some microseconds; not a serious advantage though, IMO.
On the other hand, moving away from UTC breaks backwards compatibility, 
which is definitely a drawback.

> With variant 1) and 3) it is not enough to know the new tz-data
> as this would lead the appointment to be in displayed at 17:00
> time and 13:00 UTC where it shouldn't be.

This is only correct, if the principal source if TZ-data is external to the 
PIM-client, as otherwise the knowledge of new TZ-data would come exactly in 
the same go, as the adjusted date-times: hence nothing is "displayed [at 
times] where it shouldn't be".

> Conclusion: You need to save more information.

Yes, the TZ-data.

> One way to do this is to somehow rewrite
> what you save when the tz-data changes.
> This would mean a rewrite of the object,
> which was discussed at other places.

Cheers 
	Florian