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.