Re: Regression tests fail with tzdata 2024b

On Mon, Sep 16, 2024 at 7:09 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Wolfgang Walther <walther(at)technowledgy(dot)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?

Regards, Sven Klemm