Do we need to back-patch tzcode 2026b after all?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Do we need to back-patch tzcode 2026b after all?
Date: 2026-09-30 02:21:03
Message-ID: 724084.1790734863@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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]:

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(at)iana(dot)org/thread/VXIA4AU73OQL3OZ3ZBZHWIASIIVBGUJV/

Browse pgsql-hackers by date

  From Date Subject
Next Message Ayush Tiwari 2026-09-30 02:23:12 Re: [PATCH] Clear FatalError earlier during crash restart
Previous Message Rustam ALLAKOV 2026-09-30 01:50:39 Re: Improve cube GiST page splits