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

Bernhard Reiter bernhard at intevation.de
Mon Mar 28 14:59:33 CEST 2011


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.

I have to correct myself here, I had answered too quickly.

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.

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 
  and now it tells me that for May 2015 it is UTC+4
  and still Jan 2015 stays at UTC+1.

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.

With variant 1) and 3) it is not enough to now 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.

Conclusion: You need to save more information.
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.

Best,
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/20110328/5dd6b49a/attachment.sig>


More information about the format mailing list