[tz] POSIX-TZ-environment-variable-style string rules

[Alexander Belopolsky]

The tzfile.5 manual page describes the TZ string found at the end of the
version 2+ tzfiles as follows: "After the second header and data comes a
newline-enclosed, POSIX-TZ-environment-variable-style string for use in
handling instants after the last transition time stored in the file."

Consider the case when the last transition time (T) stored in the file
comes a few weeks before the first POSIX rule transition P > T.  What local
time type should be used for the the times after T, but before P?  The
strict reading of the manual page suggests that one should use the the
local time type derived from the POSIX rule for all times t >= T, but it
would be more reasonable to continue using the type that corresponds to T
for times T <= t < P.

It turns out the two alternative logics are implemented in real life.  The
glibc library switches [1] to the POSIX rule when t >= P, while the tzcode
implementation uses POSIX rule to supply additional transitions with the
first POSIX-derived transition at P.

This leads to a discrepancy between glibc and tzcode results that is best
described on the Ubuntu bug tracker (bug #1587128 [2]).

While tzcode behavior is more logical, glibc code seems to better match the
documentation and it will probably be an uphill battle to get a fix into
glibc. [3]

I think a better solution would be to make zic add a redundant transition
when the local time type corresponding to the last transition does not
match the POSIX rule.  This will ensure that tzcode and glibc produces the
same results and systems affected by this issue can be fixed by simply
upgrading the zoneinfo database.


[1]:
https://sourceware.org/git/?p=glibc.git;a=blob;f=time/tzfile.c;h=90498783993cc5ef44aff06afe7cec5550ca8096;hb=fe0cf8614836e2b08b802eb1f55abca75d558545#l681
[2]: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1587128
[3]: https://sourceware.org/ml/libc-help/2016-04/msg00000.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20160727/1529b91e/attachment.html>