On 2025-06-19 13:40, Dan Juskevicius wrote:
Hi all,
I compiled zdump/all related object files for QNX and got identical output to yours:
qcc -Vgcc_ntoaarch64le -DUSE_LTZ=0 -lintl -o zdump -O zdump.o localtime.o strftime.o
That's to be expected if you use TZDB's localtime.c and strftime.c, because they don't have whatever bug (if any) QNX has. What happens, though, if you compile link zdump.o without linking localtime.o and strftime.o? Something like this, perhaps: qcc -Vgcc_ntoaarch64le -DUSE_LTZ=0 -lintl -o zdump zdump.c
the database seems to have the correct data, and there's likely something going on under the hood on our end.
Here's another thought. When built in the default way, America/Nuuk is unusual because the time zone abbreviation "-01" does not appear in the TZif file's time zone designation table. "-01" appears only in the TZ string at the very end of the TZif file. Possibly the QNX TZif reader mishandles this situation? I just checked, and here are the current zones that have this property of a TZ string containing an abbreviation not in the time zone designation table, along with that abbreviation (there can be at most one): America/Indiana/Petersburg EDT America/North_Dakota/Beulah CDT America/Nuuk -01 Antarctica/Troll +02 Pacific/Norfolk +12 You reported that you have the problem only with America/Nuuk, so perhaps triggering the QNX bug requires something else as well. Or maybe you didn't test the other locations with this issue, as they're all pretty obscure? Anyway, to help avoid possible confusion in this area I installed the attached proposed documentation patch.