Issue with America/Nuuk tz
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; I realize that as of 2023-03-25 the America/Nuuk time zone changed its standard time from -03 to -02, but it appears that it is not represented correctly in the tzdb. All other time zones in the database appear to be represented correctly, so I'm trying to narrow down the root cause of the issue but don't know where to look. Has anyone else reported issue with the America/Nuuk tz, and if so, is there a workaround for this? Cheers, Daniel Juskevicius Systems Software Developer djuskevicius@qnx.com QNX - It all starts here ---------------------------------------------------------------------- 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.
Hi Dan, Dan Juskevicius via tz <tz@iana.org> writes:
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; I realize that as of 2023-03-25 the America/Nuuk time zone changed its standard time from -03 to -02, but it appears that it is not represented correctly in the tzdb. All other time zones in the database appear to be represented correctly, so I'm trying to narrow down the root cause of the issue but don't know where to look.
Has anyone else reported issue with the America/Nuuk tz, and if so, is there a workaround for this?
I think that change was handled in 2022 [1]. I see that -01 is used on my system with tzdb 2025b. $ rpm -qa | grep tzdata | sed 1q tzdata-2025b-1.fc42.noarch $ TZ='America/Nuuk' date --iso-8601=m 2025-06-19T00:00-01:00 Collin [1] https://lists.iana.org/hyperkitty/list/tz@iana.org/message/KWCZPPK7EWDBCAYTT...
On 2025-06-18 19:03, Collin Funk via tz wrote:
Dan Juskevicius via tz writes:
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; I realize that as of 2023-03-25 the America/Nuuk time zone changed its standard time from -03 to -02, but it appears that it is not represented correctly in the tzdb. All other time zones in the database appear to be represented correctly, so I'm trying to narrow down the root cause of the issue but don't know where to look. Has anyone else reported issue with the America/Nuuk tz, and if so, is there a workaround for this?
I think that change was handled in 2022 [1]. I see that -01 is used on my system with tzdb 2025b. $ rpm -qa | grep tzdata | sed 1q tzdata-2025b-1.fc42.noarch $ TZ='America/Nuuk' date --iso-8601=m 2025-06-19T00:00-01:00 [1] https://lists.iana.org/hyperkitty/list/tz@iana.org/message/KWCZPPK7EWDBCAYTT...
Perhaps the issue is tzdata format 3: $ head -c20 /usr/share/zoneinfo/America/Nuuk; echo; \ tail -1 /usr/share/zoneinfo/America/Nuuk TZif3 <-02>2<-01>,M3.5.0/-1,M10.5.0/0 $ MANWIDTH=72 man tzfile | awk '/^\s+Version\s3\sformat/,/^$/' Version 3 format For version‐3‐format timezone files, a TZ string (see newtzset(3)) may use the following POSIX.1‐2024 extensions to POSIX.1‐2017: First, as in TZ="<-02>2<-01>,M3.5.0/-1,M10.5.0/0", the hours part of its transition times may be signed and range from -167 through 167 instead of being limited to unsigned val‐ ues from 0 through 24. Second, as in TZ="XXX3EDT4,0/0,J365/23", DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time. Main changes appear to be in 2022g & 2023a: $ grep -h -B1 -A3 Nuuk tzdata20{22g,23a}/europe # trimmed # From Jonas Nyrup (2022-11-24): # On last Saturday in October 2023 when DST ends America/Nuuk will switch # from -03/-02 to -02/-01 -- # Greenland will not go back to winter time in fall 2023, and that # only America/Nuuk is affected (though further changes may occur). -- Zone America/Nuuk -3:26:56 - LMT 1916 Jul 28 # Godthåb -3:00 - -03 1980 Apr 6 2:00 -3:00 EU -03/-02 2023 Mar 25 22:00 -2:00 - -02 -- # From Thomas M. Steenholdt (2022-12-02): # - The bill to move America/Nuuk from UTC-03 to UTC-02 passed. # - The bill to stop observing DST did not (Greenland will stop observing DST # when EU does). -- Zone America/Nuuk -3:26:56 - LMT 1916 Jul 28 # Godthåb -3:00 - -03 1980 Apr 6 2:00 -3:00 EU -03/-02 2023 Oct 29 1:00u -2:00 EU -02/-01 -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
On Wed, 18 Jun 2025 at 20:08, Dan Juskevicius via tz <tz@iana.org> wrote:
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; I realize that as of 2023-03-25 the America/Nuuk time zone changed its standard time from -03 to -02, but it appears that it is not represented correctly in the tzdb. All other time zones in the database appear to be represented correctly, so I'm trying to narrow down the root cause of the issue but don't know where to look.
Can you provide some specific commands or minimal test code that you ran which reproduced the issue, as well as their observed output and how that differs from what you expected? Are you certain these tests are accessing tz as directly installed on your system, or could it be accessing a copy of tz data through a downstream package that may not be as up-to-date? If a system tz, what is, say, the output of `zdump -Vc 2022,2027 America/Nuuk` ? Do you observe any similar issues with America/Scoresbysund? -- Tim Parenti
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
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*se... [2]: https://urldefense.com/v3/__https://raw.githubusercontent.com/eggert/tz/refs... ---------------------------------------------------------------------- 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.
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 # zdump -i -c 2025,2026 America/Nuuk TZ="America/Nuuk" - - -02 2025-03-30 00 -01 1 2025-10-25 23 -02 But it's still misrepresenting the timezone when changing the date: # export TZ=America/Nuuk # date 061919362025.40 Thu Jun 19 19:36:40 -02 2025 At this point the database seems to have the correct data, and there's likely something going on under the hood on our end. Thanks for the help, I'll continue to look into things on our end. Cheers, Dan ________________________________ From: Dan Juskevicius <djuskevicius@qnx.com> Sent: Thursday, June 19, 2025 3:02 PM To: Paul Eggert <eggert@cs.ucla.edu> Cc: Time zone mailing list <tz@iana.org> Subject: Re: [EXTERNAL] - Re: [tz] Issue with America/Nuuk tz 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*se... [2]: https://urldefense.com/v3/__https://raw.githubusercontent.com/eggert/tz/refs... ---------------------------------------------------------------------- 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.
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.
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.
On 2025-06-20 04:58, Dan Juskevicius wrote:
Thanks for the suggestions and support so far. I'll provide an update whenever I figure out the issue.
Thank you for reporting the issue. I installed the attached proposed patches to the TZDB man pages to document it. As the second patch indicates, one way to work around the bug without fixing QNX's TZif reader would be to build TZif files with 'make ZFLAGS=-bfat'. Two downsides, though: this bloats the TZif files, and the workaround expires about a dozen years from now. So I don't recommend relying on this workaround in the long run, although it might be useful short-term.
participants (5)
-
Brian Inglis -
Collin Funk -
Dan Juskevicius -
Paul Eggert -
Tim Parenti