Re: [PATCH] initdb: map Windows' new Canadian time zone names

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: CyberNative AI CEO <ceo(at)cybernative(dot)ai>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] initdb: map Windows' new Canadian time zone names
Date: 2026-10-20 15:02:37
Message-ID: 852487.1792508557@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Apropos of this, I just read an uber-informative post on the tz
> mailing list:
> https://lists.iana.org/hyperkitty/list/tz(at)iana(dot)org/message/JBMDX4TTIU4HAUSDLOKKI3JRLYJZGUEG/
> So according to this apparently-very-well-informed person, TZDB is
> what is under the hood in modern Windows releases, and what we are
> doing in findtimezone.c is trying to map from their legacy
> representation back to underlying truth. I wonder whether what we
> should really be doing is burning that code to the ground and fetching
> data from one of their modern APIs instead. Of course question #1 is
> whether those modern APIs exist in all Windows versions we still care
> to support.

In the light of morning, that still seems like a fine idea to pursue
long-term. But I doubt we have time to make it happen before our
November releases, and even if we did, I'd be really hesitant to
put such a change into the very last release of v14.

So what I now propose to do is commit my 0001+0003, that is just
update findtimezone.c's data to be traceable to current CLDR.
If nothing happens on the more-ambitious idea then we can add
the script from 0002 at any later time.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Matheus Alcantara 2026-10-20 15:05:01 Wrong result for whole-row IS NOT NULL with dropped columns
Previous Message Harrison Booth 2026-10-20 14:19:14 Re: meson vs. llvm bitcode files