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=90498783993... [2]: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1587128 [3]: https://sourceware.org/ml/libc-help/2016-04/msg00000.html