According to the asia file, the Philippines jumped 24 hours on May 11, 1899, from -15:56:00 to +8:04:00 (they moved the international date line?) # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Manila -15:56:00 - LMT 1844 Dec 31 8:04:00 - LMT 1899 May 11 8:00 Phil +08/+09 1942 May 9:00 - +09 1944 Nov 8:00 Phil +08/+09 Yet zdump shows only a 4-minute step in local time, rather than the expected 24-hour step: # zdump -c 1815,2018 -v Asia/Manila Asia/Manila -9223372036854775808 = NULL Asia/Manila -9223372036854689408 = NULL Asia/Manila Tue Dec 31 15:55:59 1844 UT = Mon Dec 30 23:59:59 1844 LMT isdst=0 gmtoff=-57360 Asia/Manila Tue Dec 31 15:56:00 1844 UT = Wed Jan 1 00:00:00 1845 LMT isdst=0 gmtoff=29040 Asia/Manila Wed May 10 15:55:59 1899 UT = Wed May 10 23:59:59 1899 LMT isdst=0 gmtoff=29040 Asia/Manila Wed May 10 15:56:00 1899 UT = Wed May 10 23:56:00 1899 +08 isdst=0 gmtoff=28800 Asia/Manila Sat Oct 31 15:59:59 1936 UT = Sat Oct 31 23:59:59 1936 +08 isdst=0 gmtoff=28800 ... Obviously a low-priority issue, since it's more than 100 years ago, but still would be nice to know why we have a problem. It's not totally out of the realm of probability that someone will move the dateline again, perhaps if the UTC+14 parts of Kiribati were to separate from the rest of the country? :) Data gathered on a NetBSD 7.99.64 system running on amd64 hardware, and using the 2017a tzdata. I think we're still running 2016i version of tzcode. So the question(s): * is zdump wrong? * is the compiled data file wrong? * (most likely) am I just misinterpreting the data? * is this something that has already been fixed in a more recent tzcode release? +------------------+--------------------------+------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +------------------+--------------------------+------------------------+