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://datatracker.ietf.org/doc/html/rfc9636#section-3.3.2 [2]: https://raw.githubusercontent.com/eggert/tz/refs/heads/main/zdump.c