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
