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.From 6fc9b27a68ef336ff2fa08996a50c41422066ed7 Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email protected]>
Date: Thu, 19 Jun 2025 23:23:00 -0700
Subject: [PROPOSED] Document that TZ string can be unique
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* tzfile.5: Say explicitly that the TZ string can contain time
zone abbreviations and UT offsets that do not appear elsewhere in
the TZif file. Previously this was only implicit.
While we’re at it, say that numeric time zone abbreviations
should match UT offset.
---
tzfile.5 | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/tzfile.5 b/tzfile.5
index a021859d..4d3f52fc 100644
--- a/tzfile.5
+++ b/tzfile.5
@@ -138,7 +138,7 @@ already support the POSIX-required range [\-24:59:59, 25:59:59].
bytes that represent time zone designations,
which are null-terminated byte strings, each indexed by the
.B tt_desigidx
-values mentioned above.
+values mentioned above, and each corresponding to a time zone abbreviation.
The byte strings can overlap if one is a suffix of the other.
The encoding of these strings is not specified.
.IP \(bu
@@ -221,6 +221,7 @@ after the last transition time stored in the file
or for all instants if the file has no transitions.
The TZ string is empty (i.e., nothing between the newlines)
if there is no proleptic representation for such instants.
+.PP
If non-empty, the TZ string must agree with the local time
type after the last transition time if present in the eight-byte data;
for example, given the string
@@ -229,6 +230,10 @@ then if a last transition time is in July, the transition's local time
type must specify a daylight-saving time abbreviated
.q "WEST"
that is one hour east of UT.
+.PP
+The TZ string can contain time zone abbreviations and UT offsets that
+do not appear elsewhere in the TZif file.
+.PP
Also, if there is at least one transition, time type 0 is associated
with the time period from the indefinite past up to but not including
the earliest transition time.
@@ -289,7 +294,7 @@ time, TZif readers should either refuse to process
post-expiration timestamps, or process them as if the expiration
time did not exist (possibly with an error indication).
.PP
-Time zone designations should consist of at least three (3)
+Time zone abbreviations should consist of at least three (3)
and no more than six (6) ASCII characters from the set of
alphanumerics,
.q "\-",
@@ -298,6 +303,10 @@ and
This is for compatibility with POSIX requirements for
time zone abbreviations.
.PP
+A numeric time zone abbreviation should match the UT offset.
+For example, "+0530" should be used only if the UT offset is 5.5 hours
+ahead of UT, and "\-00" should be used only if the UT offset is zero.
+.PP
When reading a version 2 or higher file, readers
should ignore the version 1 header and data block except for
the purpose of skipping over them.
--
2.48.1
