Re: More tzdb fun: POSIXRULES is being deprecated upstream
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Date: 2020-06-18T23:17:34Z
Lists: pgsql-hackers
I wrote: > ... We should expect that, starting probably this fall, there > will be installations with no posixrules file. > The minimum thing that we have to do, I'd say, is to change the > documentation to explain what happens if there's no posixrules file. > However, in view of the fact that the posixrules feature doesn't work > past 2037 and isn't going to be fixed, maybe we should just nuke it > now rather than waiting for our hand to be forced. I'm not sure that > I've ever heard of anyone replacing the posixrules file anyway. > (The fallback case is actually better in that it works for dates past > 2037; it's worse only in that you can't configure it.) 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. The cause of the failure is that we set the timezone for all regression tests to just 'PST8PDT', which is exactly the underspecified POSIX syntax that is affected by the posixrules feature. So, with the fallback rule of "M3.2.0,M11.1.0" (which corresponds to US law since 2007) we get the wrong answers for some old test cases involving dates in 2005. I'm inclined to think that the simplest fix is to replace 'PST8PDT' with 'America/Los_Angeles' as the standard zone setting for the regression tests. We definitely should be testing behavior with time-varying DST laws, and we can no longer count on POSIX-style zone names to do that. Another point, which I've not looked into yet, is that I'd always supposed that PST8PDT and the other legacy US zone names would result in loading the zone files of those names, ie /usr/share/zoneinfo/PST8PDT and friends. This seems not to be happening though. Should we try to make it happen? It would probably result in fewer surprises once posixrules goes away, because our regression tests are likely not the only users of these zone names. (I'd still be inclined to do the first thing though; it seems to me that the historical behavior of 'America/Los_Angeles' is way more likely to hold still than that of 'PST8PDT'. The IANA crew might nuke the latter zone entirely at some point, especially if the repeated proposals to get rid of DST in the US ever get anywhere.) regards, tom lane
Commits
-
Remove support for timezone "posixrules" file.
- ea57e531b948 14.0 landed
- 21aac2ff96e3 13.0 landed
-
Future-proof regression tests against possibly-missing posixrules file.
- 577dcf890cdb 13.0 landed
- 2c8ef9363db1 14.0 landed
- e7c183cd1fd1 11.9 landed
- b22ca7648b6f 12.4 landed
- 9496908d465e 9.6.19 landed
- 91e27a3e80b6 10.14 landed
- 34ef5863c77b 9.5.23 landed
-
Doc: document POSIX-style time zone specifications in full.
- 070f49005350 11.9 landed
- c10dc2d11791 13.0 landed
- 3b8210da32c4 12.4 landed
- a3235a53ae9f 14.0 landed
- 28fa0484efe9 10.14 landed
- 28589a8350d3 9.6.19 landed
- 089a63ec80e0 9.5.23 landed
-
Please find attached diffs for documentation and simple regression
- b2b6548c79eb 8.1.0 cited