From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,  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: <13181.1562082452@sss.pgh.pa.us> (Tom Lane's message of "Tue, 02
	Jul 2019 11:47:32 -0400")
Message-ID: <87k1cypeym.fsf@news-spur.riddles.org.uk>
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>
	<13181.1562082452@sss.pgh.pa.us>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix)
Date: Thu, 04 Jul 2019 06:57:19 +0100
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 Tom> I'm dubious that relying on zone[1970].tab would improve matters
 Tom> substantially; it would fix some cases, but I don't think it would
 Tom> fix all of them. Resolving all ambiguous zone-name choices is not
 Tom> the charter of those files.

Allowing zone matching by _content_ (as we do) rather than by name does
not seem to be supported in any respect whatever by the upstream data;
we've always been basically on our own with that.

[tl/dr for what follows: my proposal reduces the number of discrepancies
from 91 (see previously posted list) to 16 or 7, none of which are new]

So here are the ambiguities that are not resolvable at all:

Africa/Abidjan -> GMT

This happens because the Africa/Abidjan zone is literally just GMT even
down to the abbreviation, and we don't want to guess Africa/Abidjan for
all GMT installs.

America/Argentina/Rio_Gallegos -> America/Argentina/Ushuaia
Asia/Kuala_Lumpur -> Asia/Singapore

These are cases where zone1970.tab, despite its name, includes
distinctly-named zones which are distinct only for times in the far past
(before 1920 or 1905 respectively). They are otherwise identical by
content. We therefore end up choosing arbitrarily.

In addition, the following collection of random islands have timezones
which lack local abbreviation names, recent offset changes, or DST, and
are therefore indistinguishable by content from fixed-offset zones like
Etc/GMT+2:

Etc/GMT-4 ==
  Indian/Mahe
  Indian/Reunion

Etc/GMT-7 == Indian/Christmas
Etc/GMT-9 == Pacific/Palau
Etc/GMT-10 == Pacific/Port_Moresby
Etc/GMT-11 == Pacific/Guadalcanal

Etc/GMT-12 ==
  Pacific/Funafuti
  Pacific/Tarawa
  Pacific/Wake
  Pacific/Wallis

Etc/GMT+10 == Pacific/Tahiti
Etc/GMT+9 == Pacific/Gambier

Etc/GMT+2 == Atlantic/South_Georgia

We currently map all of these to the Etc/GMT+x names on the grounds of
length. If we chose to prefer zone.tab names over Etc/* names for all of
these, we'd be ambiguous only for a handful of relatively small islands.

-- 
Andrew (irc:RhodiumToad)