From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: Christoph Berg <myon@debian.org>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Date: Thu, 04 Jul 2019 06:57:19 +0100
Message-ID: <87k1cypeym.fsf@news-spur.riddles.org.uk> (raw)
In-Reply-To: <13181.1562082452@sss.pgh.pa.us>
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>
>>>>> "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)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: andrew@tao11.riddles.org.uk, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, sfrost@snowman.net, andres@anarazel.de, myon@debian.org, pgsql-hackers@postgresql.org
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
In-Reply-To: <87k1cypeym.fsf@news-spur.riddles.org.uk>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox