Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mWozH-0005ej-G6 for pgsql-hackers@arkaria.postgresql.org; Sun, 03 Oct 2021 00:04:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mWozF-0007SJ-7h for pgsql-hackers@arkaria.postgresql.org; Sun, 03 Oct 2021 00:04:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mWozE-0007S5-W1 for pgsql-hackers@lists.postgresql.org; Sun, 03 Oct 2021 00:04:12 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mWozC-0006KM-C3 for pgsql-hackers@postgresql.org; Sun, 03 Oct 2021 00:04:12 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 1930426j3724944; Sat, 2 Oct 2021 20:04:02 -0400 From: Tom Lane To: Thomas Munro cc: Andrew Dunstan , Andres Freund , pgsql-hackers , Peter Eisentraut , Petr Jelinek Subject: Re: 002_types.pl fails on some timezones on windows In-reply-to: References: <20210930183641.7lh4jhvpipvromca@alap3.anarazel.de> <3204190.1633030718@sss.pgh.pa.us> <3266414.1633045628@sss.pgh.pa.us> <3714784.1633207335@sss.pgh.pa.us> <3720049.1633213595@sss.pgh.pa.us> Comments: In-reply-to Thomas Munro message dated "Sun, 03 Oct 2021 11:52:56 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3724942.1633219442.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 02 Oct 2021 20:04:02 -0400 Message-ID: <3724943.1633219442@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > On Sun, Oct 3, 2021 at 11:26 AM Tom Lane 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