Do we need to back-patch tzcode 2026b after all? - Mailing list pgsql-hackers

From Tom Lane
Subject Do we need to back-patch tzcode 2026b after all?
Date
Msg-id 724084.1790734863@sss.pgh.pa.us
Whole thread
Responses Re: Do we need to back-patch tzcode 2026b after all?
Re: Do we need to back-patch tzcode 2026b after all?
List 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@iana.org/thread/VXIA4AU73OQL3OZ3ZBZHWIASIIVBGUJV/



pgsql-hackers by date:

Previous
From: Rustam ALLAKOV
Date:
Subject: Re: Improve cube GiST page splits
Next
From: Ayush Tiwari
Date:
Subject: Re: [PATCH] Clear FatalError earlier during crash restart