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

[Jeroen van Meeuwen (Kolab Systems)]

Bernhard Reiter wrote:
> 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.
> 

You can't use baseline offsets one way and then completely ignore the fact you 
are supposed to use baseline offsets the other way around, too.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20110330/71e65d9f/attachment.html>