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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Date: 2019-06-20 21:07:26
Message-ID: 25297.1561064846@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2019-06-20 21:59:56 Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Previous Message Andrew Gierth 2019-06-20 20:23:25 Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-06-20 21:08:29 Re: BUG #15865: ALTER TABLE statements causing "relation already exists" errors when some indexes exist
Previous Message David Fetter 2019-06-20 21:00:34 Re: Tweaking DSM and DSA limits