Do we need to back-patch tzcode 2026b after all?
Commit aeb07c55f updated our copy of the timezone code to match
upstream release 2026b. But I skipped our historical practice of
simultaneously back-patching into released branches, arguing that
"there are few pressing reasons for a back-patch". However,
I read this in tzdb's latest release notice [1]https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/thread/VXIA4AU73OQL3OZ3ZBZHWIASIIVBGUJV/:
NOTE FOR 2026b TEMPORARY HACK FOR CLDR AND CANADA:
This temporary hack works around a Canadian timekeeping bug in
Unicode CLDR 48 and earlier. Unfortunately it also causes zic
2023d through 2026a, in the default slim mode, to generate a
TZif file that does not conform to Internet RFC 9636 §3.3.
The buggy file in turn causes some TZif readers, including tzcode
itself, to ignore America/Vancouver’s 2026-11-01 02:00 transition
from PDT (tm_isdst=1) to MST (tm_isdst=0). Although the buggy
file does not cause any known TZif reader to mishandle UT offsets,
caution is advised when using zic 2023d through 2026a to compile
data from more-recent tz releases.
IOW, in America/Vancouver and perhaps now also Canadian timezones
further east, our back branches may misreport whether or not those
zones are on standard time after this fall's [non] transitions.
It's possible that this is not so, because Eggert specifies above
that there's not a problem before 2023d, and we had been on 2020d.
But how good should we feel about running code that's so old that
it predates this bug?
So now I'm thinking that was a mistake and we should back-patch.
I was concerned in aeb07c55f about API changes in tzload() and
tzparse(), but we might be able to put in compatibility wrappers
for those. Or we could just decide that we doubt any extensions
are calling those directly, and accept the API/ABI break.
On the third hand, this is most likely a non-problem for the
majority of our users; I think that most people probably consume
platform-provided timezone data these days, rather than using our
own copy of zic. So perhaps it's not worth sweating over.
Thoughts?
regards, tom lane
[1]: https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/thread/VXIA4AU73OQL3OZ3ZBZHWIASIIVBGUJV/
On 30 Sep 2026, at 04:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Or we could just decide that we doubt any extensions
are calling those directly, and accept the API/ABI break.
A very unscientific search using Debian codesearch and Github didn't reveal any
extensions with such callsites (which admittedly seems like a quite plausible
result).
--
Daniel Gustafsson
I wrote:
I read this in tzdb's latest release notice [1]:
NOTE FOR 2026b TEMPORARY HACK FOR CLDR AND CANADA:
This temporary hack works around a Canadian timekeeping bug in
Unicode CLDR 48 and earlier. Unfortunately it also causes zic
2023d through 2026a, in the default slim mode, to generate a
TZif file that does not conform to Internet RFC 9636 §3.3.
The buggy file in turn causes some TZif readers, including tzcode
itself, to ignore America/Vancouver’s 2026-11-01 02:00 transition
from PDT (tm_isdst=1) to MST (tm_isdst=0). Although the buggy
file does not cause any known TZif reader to mishandle UT offsets,
caution is advised when using zic 2023d through 2026a to compile
data from more-recent tz releases.
IOW, in America/Vancouver and perhaps now also Canadian timezones
further east, our back branches may misreport whether or not those
zones are on standard time after this fall's [non] transitions.
It's possible that this is not so, because Eggert specifies above
that there's not a problem before 2023d, and we had been on 2020d.
But how good should we feel about running code that's so old that
it predates this bug?
I tested this by installing the new tzdata into a back branch and
hot-wiring GetCurrentTimestamp() to deliver times a couple months
in the future (after the 1-Nov effective date of these changes).
AFAICS we do give the expected outputs: the UTC offset for
America/Vancouver is -7 hours, abbreviation is MST, is_dst false.
So at least as far as this issue is concerned, there's still not
an urgent reason to back-patch.
If we did back-patch aeb07c55f, then in addition to possibly
band-aiding the API break, we'd need to back-patch 85656c1be,
0d8e41fe1, 040932c31, and maybe part of 5f14f8228. Right at
the moment I can't get excited about doing all that to guard
against purely-hypothetical issues. Might regret it later :-(
regards, tom lane