On 12/13/22 21:23, Dave Rolsky via tz wrote:
Actually, I think the issue was with the version of zdump I was using. Apparently it didn't work properly with the latest tz data. This is a bit weird since Ubuntu released an update with the 2022g changes, but apparently the zdump binary is part of a different package, and it hasn't been updated since April, AFAICT.
Very weird, since old zdump should work with new tzdata, within reason. And I don't observe the problem on an Ubuntu 20.04.5 LTS x86-64 host with current patches that include tzdata 2022g (see transcript below). So I suspect you have a corrupted copy of America/Ojinaga, or something like that. I am attaching my system's copy which you should be able to test by using its absolute file name, e.g., by running "zdump -V -c 2022,2023 /tmp/Ojinaga" if you save it into /tmp. $ grep VERSION= /etc/os-release VERSION="20.04.5 LTS (Focal Fossa)" $ dpkg-query -l tzdata | grep tzdata ii tzdata 2022g-0ubuntu0.20.04.1 all time zone and daylight-saving time data $ ls -l /usr/share/zoneinfo/America/Ojinaga -rw-r--r-- 1 root root 1524 Dec 1 04:54 /usr/share/zoneinfo/America/Ojinaga $ zdump --version zdump (Ubuntu GLIBC 2.31-0ubuntu9.9) 2.31 $ zdump -V -c 2022,2023 America/Ojinaga America/Ojinaga Sun Mar 13 08:59:59 2022 UT = Sun Mar 13 01:59:59 2022 MST isdst=0 gmtoff=-25200 America/Ojinaga Sun Mar 13 09:00:00 2022 UT = Sun Mar 13 03:00:00 2022 MDT isdst=1 gmtoff=-21600 America/Ojinaga Sun Oct 30 07:59:59 2022 UT = Sun Oct 30 01:59:59 2022 MDT isdst=1 gmtoff=-21600 America/Ojinaga Sun Oct 30 08:00:00 2022 UT = Sun Oct 30 02:00:00 2022 CST isdst=0 gmtoff=-21600