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