Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Date
Msg-id 5560.1564668481@sss.pgh.pa.us
Whole thread Raw
In response to Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Shay Rojansky <roji@roji.org>)
Responses Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Shay Rojansky <roji@roji.org>)
Re: UCT (Re: pgsql: Update time zone data files to tzdata release2019a.)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Shay Rojansky <roji@roji.org> writes:
>> I'm not sure we're any closer to a meeting of the minds on whether
>> consulting zone[1970].tab is a good thing to do, but we got an actual
>> user complaint[1] about how "localtime" should not be a preferred
>> spelling.  So I want to go ahead and insert the discussed anti-preference
>> against "localtime" and "posixrules", as per 0001 below.  If we do do
>> something with zone[1970].tab, we'd still need these special rules,
>> so I don't think this is blocking anything.

> Just want to stress this point from a PostgreSQL driver maintainer
> perspective (see here[1] for the full details). Having "localtime" as the
> PostgreSQL timezone basically means that the timezone is completely opaque
> from a client point of view - there is no way for clients to know what
> actual timezone the server is in, and react to that. This is a limiting
> factor in client development, I hope a consensus on this specific point can
> be reached.

I have in fact committed that patch.  It won't do anything for your
problem with respect to existing installations that may have picked
"localtime", but it'll at least prevent new initdb runs from picking
that.

            regards, tom lane


Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3754113f3] 2019-07-26 12:45:32 -0400
Branch: REL_12_STABLE [e31dfe99c] 2019-07-26 12:45:52 -0400
Branch: REL_11_STABLE [4459266bf] 2019-07-26 12:45:57 -0400
Branch: REL_10_STABLE [ae9b91be7] 2019-07-26 12:46:03 -0400
Branch: REL9_6_STABLE [51b47471f] 2019-07-26 12:46:10 -0400
Branch: REL9_5_STABLE [9ef811742] 2019-07-26 12:46:15 -0400
Branch: REL9_4_STABLE [6c4ffab76] 2019-07-26 12:46:20 -0400

    Avoid choosing "localtime" or "posixrules" as TimeZone during initdb.

    Some platforms create a file named "localtime" in the system
    timezone directory, making it a copy or link to the active time
    zone file.  If Postgres is built with --with-system-tzdata, initdb
    will see that file as an exact match to localtime(3)'s behavior,
    and it may decide that "localtime" is the most preferred spelling of
    the active zone.  That's a very bad choice though, because it's
    neither informative, nor portable, nor stable if someone changes
    the system timezone setting.  Extend the preference logic added by
    commit e3846a00c so that we will prefer any other zone file that
    matches localtime's behavior over "localtime".

    On the same logic, also discriminate against "posixrules", which
    is another not-really-a-zone file that is often present in the
    timezone directory.  (Since we install "posixrules" but not
    "localtime", this change can affect the behavior of Postgres
    with or without --with-system-tzdata.)

    Note that this change doesn't prevent anyone from choosing these
    pseudo-zones if they really want to (i.e., by setting TZ for initdb,
    or modifying the timezone GUC later on).  It just prevents initdb
    from preferring these zone names when there are multiple matches to
    localtime's behavior.

    Since we generally prefer to keep timezone-related behavior the
    same in all branches, and since this is arguably a bug fix,
    back-patch to all supported branches.

    Discussion: https://postgr.es/m/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com
    Discussion: https://postgr.es/m/27991.1560984458@sss.pgh.pa.us



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Store FullTransactionId in TwoPhaseFileHeader/GlobalTransactionData
Next
From: Tom Lane
Date:
Subject: Re: Partial join