Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, Christoph Berg <myon@debian.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-06-20T21:07:26Z
Lists: pgsql-hackers 
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> Keep in mind that dealing with whatever tzdb chooses to ship is
>  Tom> not optional from our standpoint. Even if we'd refused to import
>  Tom> 2019a, every installation using --with-system-tzdata (which, I
>  Tom> sincerely hope, includes most production installs) is going to
>  Tom> have to deal with it as soon as the respective platform vendor
>  Tom> gets around to shipping the tzdata update. So reverting that
>  Tom> commit was never on the table.

> Exactly. But that means that if the combination of our arbitrary rules
> and the data in the tzdb results in an undesirable result, then we have
> no real option but to fix our rules (we can't reasonably expect the tzdb
> upstream to choose zone names to make our alphabetical-order preference
> come out right).

My position is basically that having TimeZone come out as 'UCT' rather
than 'UTC' (affecting no visible behavior of the timestamp types, AFAIK)
was not such a grave problem as to require violating community norms
to get it fixed in this week's releases rather than the next batch.

I hadn't had time to consider your patch last week because I was (a)
busy with release prep and (b) sick as a dog.  I figured we could let
it slide and discuss it after the release work died down.  I imagine
the reason you got zero other responses was that nobody else thought
it was of life-and-death urgency either.

Anyway, as I said already, my beef is not with the substance of the
patch but with failing to follow community process.  One "yes" vote
and one "no" vote do not constitute consensus.  You had no business
assuming that I would reverse the "no" vote.

			regards, tom lane

Commits

  1. Tweak our special-case logic for the IANA "Factory" timezone.

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

  3. Prefer timezone name "UTC" over alternative spellings.

  4. Attempt to identify system timezone by reading /etc/localtime symlink.

  5. Update time zone data files to tzdata release 2019a.