From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: More tzdb fun: POSIXRULES is being deprecated upstream
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1389.1562258309.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 04 Jul 2019 12:38:29 -0400
Message-ID: <1390.1562258309@sss.pgh.pa.us>
Precedence: bulk

Paul Eggert, in https://mm.icann.org/pipermail/tz/2019-June/028172.html:
> zic=E2=80=99s -p option was intended as a transition from historical
> System V code that treated TZ=3D"XXXnYYY" as meaning US
> daylight-saving rules in a time zone n hours west of UT,
> with XXX abbreviating standard time and YYY abbreviating DST.
> zic -p allows the tzdata installer to specify (say)
> Europe/Brussels's rules instead of US rules.  This behavior
> is not well documented and often fails in practice; for example it
> does not work with current glibc for contemporary timestamps, and
> it does not work in tzdb itself for timestamps after 2037.
> So, document it as being obsolete, with the intent that it
> will be removed in a future version.  This change does not
> affect behavior of the default installation.

As he says, this doesn't work for post-2038 dates:

regression=3D# set timezone =3D 'FOO5BAR';
SET
regression=3D# select now();
              now              =

-------------------------------
 2019-07-04 11:55:46.905382-04
(1 row)

regression=3D# select timeofday();
              timeofday              =

-------------------------------------
 Thu Jul 04 11:56:14.102770 2019 BAR
(1 row)

regression=3D# select '2020-07-04'::timestamptz;
      timestamptz       =

------------------------
 2020-07-04 00:00:00-04
(1 row)

regression=3D# select '2040-07-04'::timestamptz;
      timestamptz       =

------------------------
 2040-07-04 00:00:00-05                  <<-- should be -04
(1 row)

and this note makes it clear that the IANA crew aren't planning on fixing
that.  It does work if you write a full POSIX-style DST specification:

regression=3D# set timezone =3D 'FOO5BAR,M3.2.0,M11.1.0';
SET
regression=3D# select '2040-07-04'::timestamptz;
      timestamptz       =

------------------------
 2040-07-04 00:00:00-04
(1 row)

so I think what Eggert has in mind here is that they'll remove the
TZDEFRULES-loading logic and always fall back to TZDEFRULESTRING when
presented with a POSIX-style zone spec that lacks explicit transition
date rules.

So, what if anything should we do about this?  We do document posixrules,
very explicitly, see datatype.sgml around line 2460:

        When a daylight-savings zone abbreviation is present,
        it is assumed to be used
        according to the same daylight-savings transition rules used in th=
e
        IANA time zone database's <filename>posixrules</filename> entry.
        In a standard <productname>PostgreSQL</productname> installation,
        <filename>posixrules</filename> is the same as <literal>US/Eastern=
</literal>, so
        that POSIX-style time zone specifications follow USA daylight-savi=
ngs
        rules.  If needed, you can adjust this behavior by replacing the
        <filename>posixrules</filename> file.

One option is to do nothing until the IANA code actually changes,
but as 2038 gets closer, people are more likely to start noticing
that this "feature" doesn't work as one would expect.

We could get out front of the problem and remove the TZDEFRULES-loading
logic ourselves.  That would be a bit of a maintenance hazard, but perhaps
not too awful, because we already deviate from the IANA code in that area
(we have our own ideas about when/whether to try to load TZDEFRULES).

I don't think we'd want to change this behavior in the back branches,
but it might be OK to do it as a HEAD change.  I think I'd rather do
it like that than be forced into playing catchup when the IANA code
does change.

A more aggressive idea would be to stop supporting POSIX-style timezone
specs altogether, but I'm not sure I like that answer.  Even if we could
get away with it from a users'-eye standpoint, I think we have some
internal dependencies on being able to use such specifications.

			regards, tom lane