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 [email protected] QNX - It all starts here ________________________________ From: Paul Eggert <[email protected]> Sent: Thursday, June 19, 2025 1:49 PM To: Dan Juskevicius <[email protected]> Cc: Time zone mailing list <[email protected]> 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.
