On 2025-12-16 00:10, renchunhui2025--- via tz wrote:
After further investigation, we found that zdump is actually able to comprehensively detect invalid tzfiles, including cases that may later trigger aborts at runtime.
Thanks for looking into this. However, I doubt whether any zdump implementation does a comprehensive test, in the sense of checking for strict conformance to every requirement specified by Internet RFC 9636. More likely, each zdump implementation checks only for problems of concern to it.
when zdump loads certain malformed tzfiles, it can hit assertions in tzfile.c and abort with exit code 134
tzfile.c is not part of tzcode so I assume you're talking about the GNU C Library's tzfile.c, which is a TZif file reader. I could not reproduce the problem that you mentioned: when I built TZDB zdump like this: make clean make CFLAGS='-DUSE_LTZ=0' TZDOBJS=zdump.o zdump on Fedora 42 x86-64, which has glibc-2.41-11.fc42.x86_64, zdump did not hit any assertions with the test case you provided, namely:
Rule NOS 1970 2037 - Jan 27 23:43:01 2:0 SDST Rule NOS 1970 2037 - Jan 28 0:51:01 0 S Zone OS/NOS +7:0:0 NOS NO%s
Perhaps you are using a different version of glibc, or perhaps you are not running on x86-64, or perhaps you have an old version of zdump.c; any of these could explain why you see a problem but I do not. That being said, I looked at the TZif file generated by that test case, and it's clearly incorrect. I installed into the development repository the attached patch to fix the problem that I found; please give it a try. Perhaps this fix will be enough to address the problem you observed.