Re: Regression tests fail with tzdata 2024b - Mailing list pgsql-hackers

Wolfgang Walther <walther@technowledgy.de> writes:
> Tom Lane:
>> Also, as a real place to a greater extent
>> than "PST8PDT" is, it's more subject to historical revisionism when
>> somebody turns up evidence of local law having been different than
>> TZDB currently thinks.

> I now tried all versions of tzdata which we had in tree back to 2018g,
> they all work fine with the same regression test output. 2018g was an
> arbitrary cutoff, I just didn't try any further.

Yeah, my belly-aching above is just about hypothetical future
instability.  In reality, I'm sure America/Los_Angeles is pretty
well researched and so it's unlikely that there will be unexpected
changes in its zone history.

> In the end, we don't need a default timezone that will never change.

We do, really.  For example, there's a nonzero chance the USA will
cancel DST altogether at some future time.  (This would be driven by
politicians who don't remember the last time, but there's no shortage
of those.)  That'd likely break some of our test results, and even if
it happened not to, it'd still be bad because we'd probably lose some
coverage of the DST-transition-related code paths in src/timezone/.
So I'd really be way happier with a test timezone that never changes
but does include DST behavior.  I thought PST8PDT fit those
requirements pretty well, and I'm annoyed at Eggert for having tossed
it overboard for no benefit whatever.  But I don't run tzdb, so
here we are.

> We just need one that didn't change in a reasonable number of
> releases going backwards.

We've had this sort of fire-drill before, e.g. commit 8d7af8fbe.
It's no fun, and the potential surface area for unexpected changes
is now much greater than the few tests affected by that change.

But here we are, so I pushed your patch with a couple of other
cosmetic bits.  There are still a couple of references to PST8PDT
in the tree, but they don't appear to care what the actual meaning
of that zone is, so I left them be.

This is an unfortunate change as this will break extensions tests using pg_regress for testing. We run our tests against multiple minor versions and this getting backported means our tests will fail with the next minor pg release. Is there a workaround available to make the timezone for pg_regress configurable without going into every test?