The recent change to the Pacific/Fiji data added a transition from +1300 to
+1200 at 2018-01-17 03:00 local time, which is just before the maximum 32-bit
signed time_t value. Previously, that transition was just after the 32-bit
boundary.
This change exposed a curious bug in the interaction between zic and localtime.c
on platforms with signed 32-bit time_t. For the benefit of older systems, zic
outputs explicit transitions for years in the range 1900 through 2037, relying
on the POSIX-TZ-style string (for Pacific/Fiji, "FJT-12FJST,M11.1.0,M1.3.0/3")
at the end of the tzfile for transitions outside that range. Although newer
versions of localtime.c should use the POSIX-TZ-style string for time stamps in
the year 2038, if time_t is a signed 32-bit integer these localtime.c versions
mishandle Fijian time stamps from 2038-01-16 14:00:00 through 2038-01-19
03:14:07 UTC. This bug is fixed by the attached patch.
I discovered this bug during release testing, and will squeeze the attached
patch into the next tz release which I plan to make shortly. It strikes me,
though, that perhaps zic should be changed too, to better accommodate buggy
localtime implementations. If the zic cutoff for old-style transitions is at
2038-01-19 03:14:08 UTC, rather than at 2038-01-01, buggy localtime code should
do the right thing. I don't want to install such a change into zic without some
thought and/or discussion and/or testing, though; it can wait until a later release.
