On Sun, Oct 3, 2021 at 11:26 AM Tom Lane <t...@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.
