I think you're on to something here, Paul. The other zones you mentioned have the same issue as America/Nuuk; off by one hour. I'll need to look into this further to see what the problem is. I also recompiled zdump as you suggested, and the output now is markedly different:
qcc -Vgcc_ntoaarch64le -DUSE_LTZ=0 -lintl -o zdump zdump.c # zdump -i -c 2025,2026 America/Nuuk TZ="America/Nuuk" - - -02 Thanks for the suggestions and support so far. I'll provide an update whenever I figure out the issue. Cheers, Daniel Juskevicius Systems Software Developer [email protected] QNX - It all starts here ________________________________ From: Paul Eggert <[email protected]> Sent: Friday, June 20, 2025 2:28 AM To: Dan Juskevicius <[email protected]> Cc: Time zone mailing list <[email protected]> Subject: Re: [EXTERNAL] - Re: [tz] Issue with America/Nuuk tz CAUTION - This email is from an external source. Please be cautious with links and attachments. (go/taginfo) 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. ---------------------------------------------------------------------- This email and any attachments are intended solely for the use of the individual or entity to whom they are addressed. This email may contain information that is confidential, privileged, or otherwise protected from disclosure. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this email in error, please immediately contact the sender and delete all copies of this email and any attachments from your systems. Any unauthorized review, use, dissemination, distribution, or reproduction of this email by unintended recipients is not authorized and may be unlawful. Thank you for your cooperation.
