I wrote:
> I experimented with removing the posixrules support, and was quite glad
> I did, because guess what: our regression tests fall over. If we do
> nothing we can expect that they'll start failing on various random systems
> come this fall.
To clarify, you can produce this failure without any code changes:
build a standard installation (*not* using --with-system-tzdata),
remove its .../share/timezone/posixrules file, and run "make
installcheck". So builds that do use --with-system-tzdata will fail both
"make check" and "make installcheck" if the platform's tzdata packager
decides to get rid of the posixrules file.
However, on closer inspection, all the test cases that depend on 'PST8PDT'
are fine, because we *do* pick up the zone file by that name. The cases
that fall over are a few in horology.sql that depend on
SET TIME ZONE 'CST7CDT';
There is no such zone file, because that's a mistake: the central US
zone is more properly rendered 'CST6CDT'. So this is indeed a bare
POSIX zone specification, and its behavior changes if there's no
posixrules file to back-fill knowledge about pre-2007 DST laws.
These test cases originated in commit b2b6548c7. That was too long ago
to be sure, but I suspect that the use of a bogus zone was just a thinko;
there's certainly nothing in the commit log or the text of the patch
suggesting that it was intentional. Still, it seems good to be testing
our POSIX-zone-string code paths, so I'm inclined to leave it as CST7CDT
but remove the dependence on posixrules by adding an explicit transition
rule.
Also, I notice a couple of related documentation issues:
* The same commit added a documentation example that also cites CST7CDT.
That needs to be fixed to correspond to something that would actually
be used in the real world, probably America/Denver. Otherwise the
example will fail to work for some people.
* We should add something to the new appendix about POSIX zone specs
pointing out that while EST5EDT, CST6CDT, MST7MDT, PST8PDT look like they
are POSIX strings, they actually are captured by IANA zone files, so
that they produce valid historical US DST transitions even when a
plain POSIX string wouldn't.
I'm less excited than I was yesterday about removing the tests' dependency
on 'PST8PDT'. It remains possible that we might need to do that someday,
but I doubt it'd happen without plenty of warning.
regards, tom lane