The attached change (which also appears in tab-mangled form below) dealt with the problem on the system I'm using. It arranges things so that when the step-by-half-a-day time value goes over the maximum cutoff time, a final transition test is made.

(This seems better than excusing the behavior based on zdump.8's language about cutoffs being "near the starts of the years.")

    @dashdashado

1.1
927 lines
1.2
927 lines
*** /tmp/,azdump.c    2014-09-06 19:56:41.335772400 -0400
--- /tmp/,bzdump.c    2014-09-06 19:56:41.423777400 -0400
***************
*** 654,665 ****
          tmp = my_localtime_rz(tz, &t, &tm);
          if (tmp)
            ab = saveabbr(&abbrev, &abbrevsize, &tm);
!         for ( ; ; ) {
              newt = (t < absolute_max_time - SECSPERDAY / 2
                  ? t + SECSPERDAY / 2
                  : absolute_max_time);
              if (cuthitime <= newt)
!                 break;
              newtmp = localtime_rz(tz, &newt, &newtm);
              if ((tmp == NULL || newtmp == NULL) ? (tmp != newtmp) :
                  (delta(&newtm, &tm) != (newt - t) ||
--- 654,665 ----
          tmp = my_localtime_rz(tz, &t, &tm);
          if (tmp)
            ab = saveabbr(&abbrev, &abbrevsize, &tm);
!         while (t < cuthitime) {
              newt = (t < absolute_max_time - SECSPERDAY / 2
                  ? t + SECSPERDAY / 2
                  : absolute_max_time);
              if (cuthitime <= newt)
!                 newt = cuthitime;
              newtmp = localtime_rz(tz, &newt, &newtm);
              if ((tmp == NULL || newtmp == NULL) ? (tmp != newtmp) :
                  (delta(&newtm, &tm) != (newt - t) ||



On Sat, Sep 6, 2014 at 6:54 PM, Tim Parenti <tim@timtimeonline.com> wrote:
While sorting out some issues for tzdist, I noticed a bug in zdump, which is still present in 2014g.

Running zdump on Asia/Singapore for both 1981 and 1982 together produces the expected transition from UTC+7:30 to UTC+8 at the boundary between those years:

$ ./zdump.exe -vc 1981,1983 Asia/Singapore
Asia/Singapore  -9223372036854775808 = NULL
Asia/Singapore  -9223372036854689408 = NULL
Asia/Singapore  Thu Dec 31 16:29:59 1981 UT = Thu Dec 31 23:59:59 1981 SGT isdst=0
Asia/Singapore  Thu Dec 31 16:30:00 1981 UT = Fri Jan  1 00:30:00 1982 SGT isdst=0
Asia/Singapore  9223372036854689407 = NULL
Asia/Singapore  9223372036854775807 = NULL


However, running it on 1981 and 1982 individually does not:

$ ./zdump.exe -vc 1981,1982 Asia/Singapore
Asia/Singapore  -9223372036854775808 = NULL
Asia/Singapore  -9223372036854689408 = NULL
Asia/Singapore  9223372036854689407 = NULL
Asia/Singapore  9223372036854775807 = NULL

$ ./zdump.exe -vc 1982,1983 Asia/Singapore
Asia/Singapore  -9223372036854775808 = NULL
Asia/Singapore  -9223372036854689408 = NULL
Asia/Singapore  9223372036854689407 = NULL
Asia/Singapore  9223372036854775807 = NULL


Initially, I thought this might have to do with the fact that the transition is specified as a Zone continuation line rather than as a Rule, since zdump properly handled my extended edge-case examples to Jon Skeet a while back:
http://mm.icann.org/pipermail/tz/2014-July/021162.html

zdump also properly handles Asia/Dhaka's DST transition at the end of 2009, but fails in some other similar cases.

So it looks like it's more to do with the transition taking place too close to the year boundary.  Part of the problem may be the transition happening in different years, UTC and local, but that doesn't seem to be all that's going on.

Attached are some test cases to run against various versions of Singapore with 1981,1982 and 1982,1983; and various versions of Dhaka with 2009,2010 and 2010,2011.  All of these should work, but most currently don't.  (The ones that do are marked.)
-- 
Tim Parenti