Happy leap second.

In 2016i Pacific/Tongatapu changed to:

 (1) use numeric time zone abbreviations, and

 (2) observe DST from the first Sunday in November through the third Sunday in January.

That is, its POSIX future rule became "<+13>-13<+14>,M11.1.0,M1.3.0/3".

(1) results, under WORK_AROUND_QTBUG_53071, in zic adding a "y2038_boundary - 1" (i.e., 2038-01-19 03:14:07 +00:00) no-op transition to the end of the generated transitions.  So, the Pacific/Tongatapu zoneinfo file looks like ...

      :

  2115810000 gmtoff=46800 is_dst=F abbr="+13"

  2140606800 gmtoff=50400 is_dst=T abbr="+14"

  2147483647 gmtoff=50400 is_dst=T abbr="+14"

When loading Pacific/Tongatapu at runtime, (2) results in tzloadbody() generating additional transitions ...

      :

  2140606800 gmtoff=50400 is_dst=T abbr="+14"

  2147259600 gmtoff=46800 is_dst=F abbr="+13"

  2172661200 gmtoff=50400 is_dst=T abbr="+14"

  2178709200 gmtoff=46800 is_dst=F abbr="+13"

      :

When those generated transitions are patched onto the end of the zic transitions, we end up with ...

  2115810000 gmtoff=46800 is_dst=F abbr="+13"

  2140606800 gmtoff=50400 is_dst=T abbr="+14"

  2147483647 gmtoff=50400 is_dst=T abbr="+14"

  2172661200 gmtoff=50400 is_dst=T abbr="+14"

  2178709200 gmtoff=46800 is_dst=F abbr="+13"

  

This is wrong.  The presence of the 2147483647 transition caused us to drop the 2147259600 transition.  That is, we lost the shift out of DST at 2038-01-17 02:00:00 +13:00 (2038-01-16 13:00:00 +00:00).

One solution would be to trim trailing, no-op transitions from the end of the zic transitions before adding the rule-generated ones.  The reference implementation doesn't need them.

Bradley