Re: More tzdb fun: POSIXRULES is being deprecated upstream - Mailing list pgsql-hackers

From Tom Lane
Subject Re: More tzdb fun: POSIXRULES is being deprecated upstream
Date
Msg-id 1613153.1592522254@sss.pgh.pa.us
Whole thread Raw
In response to Re: More tzdb fun: POSIXRULES is being deprecated upstream  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: More tzdb fun: POSIXRULES is being deprecated upstream
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: global barrier & atomics in signal handlers (Re: Atomicoperations within spinlocks)
Next
From: David Rowley
Date:
Subject: Re: Parallel Seq Scan vs kernel read ahead