Re: 002_types.pl fails on some timezones on windows

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Sun, Oct 3, 2021 at 11:26 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

Actually ... digging in the archives, the reason we have a special case
for Central America is that there was a user complaint about the previous
mapping to CST6CDT:

https://www.postgresql.org/message-id/flat/1316149023380-4809498.post%40n5.nabble.com

CST6CDT was *way* wrong, because it implies USA DST rules, so the
complaint was well-founded. I wrote in that thread:

> I think we ought to map "Central America Standard Time" to plain CST6.
> (Or we could map to one of America/Costa_Rica, America/Guatemala,
> America/El_Salvador, etc, but that seems more likely to offend people in
> the other countries than provide any additional precision.)

However, if we can cite CLDR as authority, I see no reason why
America/Guatemala should be any more offensive than any of the
other fairly-arbitrary choices CLDR has made. None of those
zones have observed DST for a decade or more, so at least in
recent years it wouldn't make any difference anyway.

So, I'm now sold on just making all our mappings match CLDR.
I'll do that in a couple of days if I don't hear objections.

> 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?

That seems like potentially a nice long-term solution, but it doesn't
sound likely to be back-patchable. So I'd like to get the existing
data in as good shape as we can before we go looking for a replacement
mechanism.

regards, tom lane