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

Bernhard Reiter bernhard at intevation.de
Thu Mar 24 11:43:14 CET 2011

Am Donnerstag, 24. März 2011 11:12:42 schrieb Jeroen van Meeuwen (Kolab 
> Bernhard Reiter wrote:
> > 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.
> Variant 1) works too, if the specification is to write and read the
> datetime as the timestamp corresponding with the target time using the
> baseline UTC offset only

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.

My reading of rfc3339: Using a "baseline" UTC offset would not 
be local time as mentioned in "4.2 Local Offsets". Furthermore, the rules
you propose seem to be much more complicated.

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/20110324/a5ec4bce/attachment.sig>

More information about the format mailing list