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

[Bernhard Reiter]

Florian,

Am Donnerstag, 31. März 2011 19:44:39 schrieb Florian v. Samson:
> 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

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

You are correct, I've made a mistake when writing this and corrected it later
in http://kolab.org/pipermail/kolab-format/2011-March/001291.html
which is the email you responded to in here.

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

Good assumption.

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

It is true: Different clients with different tz-data bases would display
the time inconsistently. The evaluation if this is worse or better
is not so easy, this is discussion
c) [1] Which failure is better: all clients a wrong time but consistent,
   clients inconsistent, but some showing the right time?

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

-> c).

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

Yes, the problem is to get the right UTC.

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

I agree: irrelevant.

> On the other hand, moving away from UTC breaks backwards compatibility,
> which is definitely a drawback.

Putting the result of the evaluation aside.
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

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.

Which brings us to again to
b) Pros and cons of re-writing the objects when tz-data changes.

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

I was refering to that just having tz-data-new is not enough when
saving time as UTC. You must know tz-data-old one way or the other.
On the other hand, using localtime + tz-id you only need to know
tz-data-new. (But you get the consistency drawback -> discussion c).)

> Yes, the TZ-data.

Yes, this is my whole point as explained above, the conclusion is:
Saving time as UTC will force rewriting of objects.

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

[1] http://kolab.org/pipermail/kolab-format/2011-April/001309.html
    

-- 
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/20110401/67bfc697/attachment.sig>