On Sun, Oct 3, 2021 at 11:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > 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.
Hah. That's a *terrible* link to have.
> 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 :-(.
It would be interesting to know if that idea of matching BCP47 locale
names to territories could address that. Perhaps we should get that
modern-locale-name patch first (I think I got stuck on "let's kill off
old Windows versions so we can use this", due to confusing versioning
and a lack of a guiding policy on our part, but I think I should just
propose something), and then revisit this?
> (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.)
I don't follow the list but there was a nice summary in LWN: "A fork
for the time-zone database?". From the peanut gallery, I thought it
was a bit of a double standard, considering the rejection of that idea
of yours about getting rid of longitude-based pre-standard times on
data stability grounds, and a lot less justifiable. I hope there
isn't a fork.
