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
djuskevicius@qnx.com

QNX - It all starts here
From: Paul Eggert <eggert@cs.ucla.edu>
Sent: Friday, June 20, 2025 2:28 AM
To: Dan Juskevicius <djuskevicius@qnx.com>
Cc: Time zone mailing list <tz@iana.org>
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.