[tz] [PATCH 3/3] * europe (Europe/Vaduz): Now a link to Europe/Zurich.

Paul Eggert eggert at cs.ucla.edu
Tue Sep 10 05:03:14 UTC 2013

Clive D.W. Feather wrote:
> don't put LMT values in the files; remove the ones that are there

Unfortunately the underlying interface requires that
*some* offset be there, and LMT is more accurate than
UTC would be, so there is an argument for keeping it
in the database so long as it's understood to be a
somewhat-flaky approximation.

That being said....

In hindsight perhaps we should have not put LMT in there,
and instead designed a data format that allows one to say
"undefined" (so presumably localtime fails).

The same goes for the transition from LMT to standard time,
which is often not reliably known even to the nearest decade
(even though the data format requires that it be specified
to one-second precision!).  But how would that be modeled
so that the caller of localtime could find this out?
Maybe localtime should return randomish values each
time you call it, if the result is not reliably known,
sort of like randomized rounding?  (I'm mostly kidding

More information about the tz mailing list