MIME-Version: 1.0
References: <0a997455-5aba-4cf2-a354-d26d8bcbfae6@technowledgy.de>
 <441306.1726346239@sss.pgh.pa.us> <38e73fef-f19b-4835-b353-a110db6c8318@technowledgy.de>
 <1043017.1726463364@sss.pgh.pa.us>
In-Reply-To: <1043017.1726463364@sss.pgh.pa.us>
From: Sven Klemm <sven@timescale.com>
Date: Mon, 16 Sep 2024 10:33:56 +0200
Message-ID: <CAMCrgp1W7DWBNA4GQCKBPyUS7nV15j_8kedkBWX2ud6w1n06Yw@mail.gmail.com>
Subject: Re: Regression tests fail with tzdata 2024b
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Wolfgang Walther <walther@technowledgy.de>, pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000878f450622386ff0"
Archived-At: <https://www.postgresql.org/message-id/CAMCrgp1W7DWBNA4GQCKBPyUS7nV15j_8kedkBWX2ud6w1n06Yw%40mail.gmail.com>
Precedence: bulk

--000000000000878f450622386ff0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 16, 2024 at 7:09=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> 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?

Regards, Sven Klemm

--000000000000878f450622386ff0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Sep 16, 2024 at 7:09=E2=80=AF=
AM Tom Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Wolfg=
ang Walther &lt;<a href=3D"mailto:walther@technowledgy.de" target=3D"_blank=
">walther@technowledgy.de</a>&gt; writes:<br>
&gt; Tom Lane:<br>
&gt;&gt; Also, as a real place to a greater extent<br>
&gt;&gt; than &quot;PST8PDT&quot; is, it&#39;s more subject to historical r=
evisionism when<br>
&gt;&gt; somebody turns up evidence of local law having been different than=
<br>
&gt;&gt; TZDB currently thinks.<br>
<br>
&gt; I now tried all versions of tzdata which we had in tree back to 2018g,=
 <br>
&gt; they all work fine with the same regression test output. 2018g was an =
<br>
&gt; arbitrary cutoff, I just didn&#39;t try any further.<br>
<br>
Yeah, my belly-aching above is just about hypothetical future<br>
instability.=C2=A0 In reality, I&#39;m sure America/Los_Angeles is pretty<b=
r>
well researched and so it&#39;s unlikely that there will be unexpected<br>
changes in its zone history.<br>
<br>
&gt; In the end, we don&#39;t need a default timezone that will never chang=
e.<br>
<br>
We do, really.=C2=A0 For example, there&#39;s a nonzero chance the USA will=
<br>
cancel DST altogether at some future time.=C2=A0 (This would be driven by<b=
r>
politicians who don&#39;t remember the last time, but there&#39;s no shorta=
ge<br>
of those.)=C2=A0 That&#39;d likely break some of our test results, and even=
 if<br>
it happened not to, it&#39;d still be bad because we&#39;d probably lose so=
me<br>
coverage of the DST-transition-related code paths in src/timezone/.<br>
So I&#39;d really be way happier with a test timezone that never changes<br=
>
but does include DST behavior.=C2=A0 I thought PST8PDT fit those<br>
requirements pretty well, and I&#39;m annoyed at Eggert for having tossed<b=
r>
it overboard for no benefit whatever.=C2=A0 But I don&#39;t run tzdb, so<br=
>
here we are.<br>
<br>
&gt; We just need one that didn&#39;t change in a reasonable number of<br>
&gt; releases going backwards.<br>
<br>
We&#39;ve had this sort of fire-drill before, e.g. commit 8d7af8fbe.<br>
It&#39;s no fun, and the potential surface area for unexpected changes<br>
is now much greater than the few tests affected by that change.<br>
<br>
But here we are, so I pushed your patch with a couple of other<br>
cosmetic bits.=C2=A0 There are still a couple of references to PST8PDT<br>
in the tree, but they don&#39;t appear to care what the actual meaning<br>
of that zone is, so I left them be.<br></blockquote><div><br></div>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 gett=
ing backported means our tests will fail with the next minor pg release. Is=
 there a workaround available to make the timezone for pg_regress configura=
ble without going into every test?</div><div><br></div><div dir=3D"ltr" cla=
ss=3D"gmail_signature"><div dir=3D"ltr">Regards, Sven Klemm</div></div></di=
v>

--000000000000878f450622386ff0--