Re: Regression tests fail with tzdata 2024b
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Wolfgang Walther <walther@technowledgy.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2024-09-14T20:37:19Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Run regression tests with timezone America/Los_Angeles.
- b28b9b19bbe3 13.17 landed
- b27622c90869 14.14 landed
- 2b94ee58bf25 15.9 landed
- 2abc88958039 16.5 landed
- 205813da4c26 12.21 landed
- b8ea0f675f35 18.0 landed
- 6283ff2018e3 17.0 landed
-
Don't require bleeding-edge timezone data in timestamptz regression test.
- 8d7af8fbe734 9.5.0 cited
Wolfgang Walther <walther@technowledgy.de> writes: > Building --with-system-tzdata and the latest tzdata 2024b fails the > regression tests for me (see attached .diffs). This seems to be because > of [1], which changed the way "PST8PDT" is handled. This is the timezone > that the regression tests are run with. That's quite annoying, especially since it was not mentioned in the 2024b release notes. (I had read the notes and concluded that 2024b didn't require any immediate attention on our part.) > From 2024b on, "PST8PDT" is the same as "America/Los_Angeles", so by > changing the regression tests to use the latter as the default, we're > getting consistent output on at least 2024a and 2024b. I'm fairly un-thrilled with this answer, not least because it exposes that zone's idiosyncratic "LMT" offset of -7:52:58 for years before 1883. (I'm surprised that that seems to affect only one or two regression results.) 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. We may not have a lot of choice though. I experimented with using full POSIX notation, that is "PST8PDT,M3.2.0,M11.1.0", but that is actually worse in terms of the number of test diffs, since it doesn't match the DST transition dates that the tests expect for years before 2007. Another objection is that the tests would then not exercise any of the mainstream tzdb-file-reading code paths within the timezone code itself. Grumble. regards, tom lane