From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Andrew Gierth <andrew@tao11.riddles.org.uk>,
        Stephen Frost <sfrost@snowman.net>,
 Andres Freund <andres@anarazel.de>,
        Christoph Berg <myon@debian.org>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release
 2019a.)
In-reply-to: 
 <CA+TgmoYK_+aVvV54qC79ZyfKoDBuDWChLT_=8JEJQRwSuu9QSA@mail.gmail.com>
References: <24452.1560285699@sss.pgh.pa.us>
 <20190614095546.GA15107@msg.df7cb.de> <26948.1560517875@sss.pgh.pa.us>
 <87ef3w3u8a.fsf@news-spur.riddles.org.uk> <7114.1560539536@sss.pgh.pa.us>
 <875zp74zpf.fsf@news-spur.riddles.org.uk>
 <871rzv4yes.fsf@news-spur.riddles.org.uk>
 <20190617173943.z3ttxqenbcwrlag4@alap3.anarazel.de>
 <20190617183458.GG2480@tamriel.snowman.net>
 <20190617183828.hj7ci362zbxd4nax@alap3.anarazel.de>
 <20190617184053.GI2480@tamriel.snowman.net>
 <CA+TgmoYF00U3Pbkh4mXhXr1NN6pKFM278KmXRS35HDuHgNcMFw@mail.gmail.com>
 <25314.1560980148@sss.pgh.pa.us> <27991.1560984458@sss.pgh.pa.us>
 <877e9h18df.fsf@news-spur.riddles.org.uk> <2643.1561508327@sss.pgh.pa.us>
 <CA+Tgmobiyxabgs4vk_Xe4Y+sbXMHfueRh8OGQsPncPFs9fosKw@mail.gmail.com>
 <1262.1561658284@sss.pgh.pa.us>
 <CA+TgmoYK_+aVvV54qC79ZyfKoDBuDWChLT_=8JEJQRwSuu9QSA@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Sat, 29 Jun 2019 16:48:12 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13180.1562082452.1@sss.pgh.pa.us>
Date: Tue, 02 Jul 2019 11:47:32 -0400
Message-ID: <13181.1562082452@sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> Long story short, I agree with you that most people probably don't
> care about this very much, but I also agree with Andrew that some of
> the current choices we're making are pretty strange, and I'm not
> convinced as you are that it's impossible to make a principled choice
> between alternatives in all cases. The upstream data appears to
> contain some information about intent; it's not just a jumble of
> exactly-equally-preferred alternatives.

I agree that if there were an easy way to discount the IANA "backward
compatibility" zone names, that'd likely be a reasonable thing to do.
The problem is that those names aren't distinguished from others in
the representation we have available to us (ie, the actual
/usr/share/zoneinfo file tree).  I'm dubious that relying on
zone[1970].tab would improve matters substantially; it would fix
some cases, but I don't think it would fix all of them.  Resolving
all ambiguous zone-name choices is not the charter of those files.

			regards, tom lane