On Mon, Sep 16, 2024 at 7:09 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
> Wolfgang Walther <walt...@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? Regards, Sven Klemm
