Happy to help make things clear - to be most accurate, you may want to add an addendum that QNX doesn't use the TZDB by default. A user must first build the database using our toolchain and then manually add it to the system; the QNX default is the POSIX format ( stdoffset[dst[offset][,start[/time],end[/time]]] ).

As for the suggestion of a potential mishandling the TZif version 3 format, the other zones that make use of that interface are represented correctly, for example:

# export TZ=America/Scoresbysund
# 
# date
Thu Jun 19 17:23:30 -01 2025
# export TZ=America/Nuuk
# 
# date
Thu Jun 19 16:23:49 -02 2025

For whatever reason, it's just the America/Nuuk TZ that reports incorrectly. And yes, all of these timestamps were from today. I'll have to put some work in to get zdump to compile for a QNX environment to confirm the zone output. Thanks for the continued help.

Cheers,

Daniel Juskevicius
Systems Software Developer
djuskevicius@qnx.com

QNX - It all starts here
From: Paul Eggert <eggert@cs.ucla.edu>
Sent: Thursday, June 19, 2025 1:49 PM
To: Dan Juskevicius <djuskevicius@qnx.com>
Cc: Time zone mailing list <tz@iana.org>
Subject: [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-18 05:06, Dan Juskevicius via tz wrote:
> Dear sir or madam,
>
> I'm currently working on an issue that one of our customers has reported with the tz database. Using the latest release (2025b), I have been able to reproduce an issue with America/Nuuk time where it reports at -02 instead of -01

Are these today's timestamps? If so, possibly QNX has trouble with TZif
version 3 format[1], as Brian mentioned. You might also check other time
zones that use version 3 format: these currently include Pacific/Easter,
America/Santiago, America/Scoresbysund, Asia/Jerusalem, Asia/Gaza, and
Asia/Hebron. To test this possibility, you can try compiling and testing
tzcode's zdump.c[2] on QNX with shell commands like this:

   gcc -DUSE_LTZ=0 -o zdump zdump.c
   ./zdump -i -c 2025,2026 America/Nuuk

For America/Nuuk the zdump output should look like this:


   TZ="America/Nuuk"
   -    -       -02
   2025-03-30   00      -01             1
   2025-10-25   23      -02

If the output differs, it's almost surely a bug in QNX's C library,
which you can investigate.

Another possibility, if your customer is talking about timestamps
earlier this year, is that the customer incorrectly assumes that Nuuk
uses US rules for DST. Nuuk uses EU rules, which means that there are
roughly three weeks in March and one week in October/November where
America/Nuuk will correctly report -02 when a US-assuming customer would
expect -01.

By the way, thanks for letting us know that QNX was using TZDB. I
installed the attached patch to note this in our list.

[1]: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9636*section-3.3.2__;Iw!!JoeW-IhCUkS0Jg!Y4uqNm7o51OiXlJQyA7KpzeVj2-gi7KtPuhixpSlSYwSwrMuNw5aoWmw2SXUOeQo_h3q4HvgxQJYBupJTwVH$
[2]: https://urldefense.com/v3/__https://raw.githubusercontent.com/eggert/tz/refs/heads/main/zdump.c__;!!JoeW-IhCUkS0Jg!Y4uqNm7o51OiXlJQyA7KpzeVj2-gi7KtPuhixpSlSYwSwrMuNw5aoWmw2SXUOeQo_h3q4HvgxQJYBrLqt22w$
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.