Wolfgang Walther <walt...@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
