Re: 002_types.pl fails on some timezones on windows - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 002_types.pl fails on some timezones on windows
Date
Msg-id 3720049.1633213595@sss.pgh.pa.us
Whole thread Raw
In response to Re: 002_types.pl fails on some timezones on windows  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: 002_types.pl fails on some timezones on windows  (Andres Freund <andres@anarazel.de>)
Re: 002_types.pl fails on some timezones on windows  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> On Sun, Oct 3, 2021 at 9:42 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> * Now-documented decision to map "Greenwich Standard Time"
>> to Europe/London, not Atlantic/Reykjavik as they have it.

> Hmm.  It's hard to pick a default from that set of merged zones, but
> the funny thing about this choice is that Europe/London is the one
> Olson zone that it's sure *not* to be, because then your system would
> be using that other name, IIUC.

Agreed, this choice is definitely formally wrong.  However, the example
we started the thread with is that Andres thought "Greenwich Standard
Time" would get him UTC, or at least something a lot less oddball than
what he got.

But wait a minute ... looking into the tzdb sources, I find that Iceland
hasn't observed DST since 1968, and tzdb spells their zone abbreviation as
"GMT" since then.  That means that Atlantic/Reykjavik is actually a way
better approximation to "plain GMT" than Europe/London is.  Maybe there
is some method in CLDR's madness here.

>> * The miscellaneous deltas shown in the attached diff, which in
>> many cases boil down to "we chose the first name mentioned for the
>> zone, while CLDR did something else".  I felt that our historical
>> mappings of these cases weren't wrong enough to justify any
>> political flak I might take for changing them.  OTOH, maybe we
>> should just say "we follow CLDR" and be done with it.

> Eyeballing these, three look strange to me in a list of otherwise
> city-based names: Pacific/Guam (instead of Port Moresby, capital of
> PNG which apparently shares zone rules with the territory of Guam) and
> Pacific/Samoa (country name instead of its capital Apia; the city
> avoids any potential confusion with American Samoa which is on the
> other side of the date line) and then "CET", an abbreviation.

Oooh.  Looking closer, I see that the Windows zone is defined as
    <!-- (UTC+13:00) Samoa -->
which makes it *definitely* Pacific/Apia ... Pacific/Samoa is a
link to Pacific/Pago_Pago which is in American Samoa, at UTC-11.
So our mapping was kind of okay up till 2011 when Samoa decided
they wanted to be on the other side of the date line, but now
it's wrong as can be.  Ooops.

> But
> debating individual points of geography and politics like this seems a
> bit silly... I wasn't really aware of this Windows->Olson zone name
> problem lurking in our tree before, but it sounds to me like switching
> to 100% "we use CLDR, if you think it's wrong, please file a report at
> cldr.unicode.org" wouldn't be a bad idea at all!

I'd still defend our exception for Central America: CLDR maps that
to Guatemala which seems pretty random, even if they haven't observed
DST there for a few years.  For the rest of it, though, "we follow CLDR"
has definitely got a lot of attraction.  The one change that makes me
nervous is adopting Europe/Berlin for "W. Europe Standard Time",
on account of the flak Paul Eggert just got from trying to make a
somewhat-similar change :-(.  (If you don't read the tz mailing list
you may not be aware of that particular tempest in a teapot, but he
tried to merge a bunch of zones into Europe/Berlin, and there were
a lot of complaints.  Some from me.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Problem with CF app?
Next
From: Kevin Burke
Date:
Subject: Re: Better context for "TAP tests not enabled" error message