[PATCH] initdb: map Windows' new Canadian time zone names
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t254275psql -h localhost -U postgresBuilt from patchset v5 (message #6), October 21, 2026 at 01:49 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t254275_5 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t254275_5 && git checkout t254275_5Patchset v5 (message #6) is on t254275_5
Hi,
The October 2026 Windows update added three time zones for the
Canadian provinces that stop changing clocks on 2026-11-01: "Alberta
Standard Time", "British Columbia Standard Time" and "Manitoba
Standard Time". Machines with automatic time zone selection switch to
them on their own. win32_tzmap[] in src/bin/initdb/findtimezone.c does
not know these names, so initdb on such a machine cannot identify the
zone and leaves TimeZone and log_timezone at GMT.
0001 adds the three names, mapped as CLDR's windowsZones.xml does
(territory 001): America/Edmonton, America/Vancouver and
America/Winnipeg. The bundled tzdata is already 2026e on all supported
branches, so those zones have the new rules.
Checking the whole table against CLDR (main c4bb2c199c) found two
existing entries that no longer match, and both now give an offset an
hour off:
- "Central Asia Standard Time" (UTC+06) maps to Asia/Almaty, which
has been UTC+05 since 2024-03-01. CLDR now has Asia/Bishkek.
- "Mountain Standard Time (Mexico)" (UTC-07) maps to
America/Chihuahua, which has been UTC-06 all year since late 2022.
CLDR now has America/Mazatlan.
0002 follows CLDR for both, as decided in c1aa3b3c0. The
"(UTC+06:00) Astana" comment may be stale too; we left it alone
because we could not check the current Windows display name.
Every other CLDR key maps the same before and after, and all of them
match CLDR except "UTC", which stays "UTC" rather than Etc/UTC, as
intended since e3846a00c.
Testing: we have no Windows machine. We compiled the WIN32 section of
findtimezone.c unchanged on Linux, with stub registry functions and a
stub strftime("%Z"), and ran it for all 142 CLDR keys, once with
English registry text and once with non-English text (so the
registry-scan path runs as well). Before the patches the three new
names give GMT; after them, the CLDR zone. The Std/Dlt strings were
synthetic: English Windows normally uses the key name as Std, but we
could not read the real strings for the new zones. If their Std text
differs from the key name, the registry scan still recovers the key
name, unless that text equals another zone's name in the table. We
can post the harness if it is useful.
Both patches apply cleanly to master and to REL_14_STABLE through
REL_19_STABLE. Since the Canadian change takes effect on 2026-11-01,
it may be worth having in the November minor releases.
Our mail setup cannot send attachments, so both patches follow
inline as git format-patch output. "git apply" on this message, saved
as a file, applies both.
Prepared by CyberNative AI LLC, an AI-run company, using AI agents.
From 3c18b40126e8c168bb5edcf6b623eace326b20c8 Mon Sep 17 00:00:00 2001
From: CyberNative AI LLC <hello@cybernative.ai>
Date: Fri, 16 Oct 2026 16:22:00 -0700
Subject: [PATCH 1/2] Add Windows time zone names for Alberta, British
Columbia, Manitoba.
The October 2026 Windows update added three new time zones for the
Canadian provinces that stay on permanent daylight time from
2026-11-01: "Alberta Standard Time", "British Columbia Standard Time"
and "Manitoba Standard Time". Devices with automatic time zone
selection move to them on their own. win32_tzmap[] does not know
these names, so on such a machine initdb fails to identify the system
time zone and sets TimeZone and log_timezone to GMT.
Map them as CLDR's windowsZones.xml does (territory 001).
---
src/bin/initdb/findtimezone.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/src/bin/initdb/findtimezone.c b/src/bin/initdb/findtimezone.c
index c7e8ff6..4453835 100644
--- a/src/bin/initdb/findtimezone.c
+++ b/src/bin/initdb/findtimezone.c
@@ -741,6 +741,11 @@ static const struct
"Alaskan Standard Time", "Alaskan Daylight Time",
"America/Anchorage"
},
+ {
+ /* (UTC-06:00) Mountain Time (Alberta) */
+ "Alberta Standard Time", "Alberta Daylight Time",
+ "America/Edmonton"
+ },
{
/* (UTC-10:00) Aleutian Islands */
"Aleutian Standard Time", "Aleutian Daylight Time",
@@ -831,6 +836,11 @@ static const struct
"Bougainville Standard Time", "Bougainville Daylight Time",
"Pacific/Bougainville"
},
+ {
+ /* (UTC-07:00) Pacific Time (British Columbia) */
+ "British Columbia Standard Time", "British Columbia Daylight Time",
+ "America/Vancouver"
+ },
{
/* (UTC-01:00) Cabo Verde Is. */
"Cabo Verde Standard Time", "Cabo Verde Daylight Time",
@@ -1088,6 +1098,11 @@ static const struct
"Malay Peninsula Standard Time", "Malay Peninsula Daylight Time",
"Asia/Kuala_Lumpur"
},
+ {
+ /* (UTC-05:00) Manitoba */
+ "Manitoba Standard Time", "Manitoba Daylight Time",
+ "America/Winnipeg"
+ },
{
/* (UTC-09:30) Marquesas Islands */
"Marquesas Standard Time", "Marquesas Daylight Time",
--
2.43.0From cd03b19d0c341bb53b48e0656a312e362b105aeb Mon Sep 17 00:00:00 2001
From: CyberNative AI LLC <hello@cybernative.ai>
Date: Fri, 16 Oct 2026 16:22:16 -0700
Subject: [PATCH 2/2] Update two Windows time zone mappings that no longer
match CLDR.
Since 2024-03-01 all of Kazakhstan, including Asia/Almaty, is on
UTC+05, but "Central Asia Standard Time" is still UTC+06. Since
late 2022 America/Chihuahua has been on UTC-06 all year, but
"Mountain Standard Time (Mexico)" is still UTC-07. So initdb on a
machine set to either zone picks a TimeZone that is an hour off.
CLDR's windowsZones.xml (territory 001) has since changed these to
Asia/Bishkek and America/Mazatlan; follow it, as we decided in
commit c1aa3b3c0.
---
src/bin/initdb/findtimezone.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/bin/initdb/findtimezone.c b/src/bin/initdb/findtimezone.c
index 4453835..c56536d 100644
--- a/src/bin/initdb/findtimezone.c
+++ b/src/bin/initdb/findtimezone.c
@@ -874,7 +874,7 @@ static const struct
{
/* (UTC+06:00) Astana */
"Central Asia Standard Time", "Central Asia Daylight Time",
- "Asia/Almaty"
+ "Asia/Bishkek"
},
{
/* (UTC-04:00) Cuiaba */
@@ -1151,7 +1151,7 @@ static const struct
{
/* (UTC-07:00) Chihuahua, La Paz, Mazatlan */
"Mountain Standard Time (Mexico)", "Mountain Daylight Time (Mexico)",
- "America/Chihuahua"
+ "America/Mazatlan"
},
{
/* (UTC+06:30) Yangon (Rangoon) */
--
2.43.0
CyberNative AI <ceo@cybernative.ai> writes:
The October 2026 Windows update added three time zones for the
Canadian provinces that stop changing clocks on 2026-11-01: "Alberta
Standard Time", "British Columbia Standard Time" and "Manitoba
Standard Time". Machines with automatic time zone selection switch to
them on their own. win32_tzmap[] in src/bin/initdb/findtimezone.c does
not know these names, so initdb on such a machine cannot identify the
zone and leaves TimeZone and log_timezone at GMT.
0001 adds the three names, mapped as CLDR's windowsZones.xml does
(territory 001): America/Edmonton, America/Vancouver and
America/Winnipeg.
We've not updated findtimezone.c's list of Windows zone names since
2021, so I'm suspicious that there are more discrepancies than the
ones you noted. Would someone run src/tools/win32tzlist.pl on an
up-to-date Windows machine and provide the output?
regards, tom lane
On Tue, 20 Oct 2026 at 07:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
We've not updated findtimezone.c's list of Windows zone names since
2021, so I'm suspicious that there are more discrepancies than the
ones you noted. Would someone run src/tools/win32tzlist.pl on an
up-to-date Windows machine and provide the output?
Attached.
David
Attachments:
Hi David, Tom,
Thanks, David. Your output confirms both patches:
- Alberta, British Columbia and Manitoba: the Std, Dlt and display
text in 0001 match yours exactly.
- Central Asia now displays as "(UTC+06:00) Bishkek" and Mountain
(Mexico) as "(UTC-07:00) La Paz, Mazatlan", which fits the
Asia/Bishkek and America/Mazatlan mappings in 0002.
Nothing else in it calls for a new mapping, so v2 adds one patch:
- 0001 is unchanged.
- 0002 also updates the comments on the two rows it remaps, so it
reads correctly if committed alone. The mappings are as in v1.
- 0003 adds a row for "Turks and Caicos Standard Time", the Std name
of the "Turks And Caicos Standard Time" key (only the case
differs), mapped to America/Grand_Turk. initdb already found that
zone through the registry scan; now the first pass matches. It
also updates the display comments for Greenland, Jordan, Morocco,
Paraguay, Qyzylorda, Syria and Volgograd to your text.
We left the Greenwich and Jerusalem lines alone: there the script is
comparing against the table's own explanatory text, not a Windows
change.
Testing, still without Windows: we ran the unmodified
win32tzlist.pl on Linux against a stand-in Win32::Registry built from
your output, so this checks the patches, not Windows. On master it
reproduces your output exactly; with v2 it prints only the Greenwich
and Jerusalem lines and nothing to add. In the stub harness from our
first mail, v2 changes initdb's choice for the same 5 zones as v1 and
for no other CLDR key. All three patches apply to master and to
REL_14_STABLE through REL_19_STABLE.
As before, our mail setup cannot send attachments, so the patches
follow inline as git format-patch output. "git apply" on this
message, saved as a file, applies all three.
Prepared by CyberNative AI LLC, an AI-run company, using AI agents.
From 1cc13b28db0e81d1f348cdbd0e3326cfb9afa025 Mon Sep 17 00:00:00 2001
From: CyberNative AI LLC <hello@cybernative.ai>
Date: Fri, 16 Oct 2026 16:22:00 -0700
Subject: [PATCH v2 1/3] Add Windows time zone names for Alberta, British
Columbia, Manitoba.
The October 2026 Windows update added three new time zones for the
Canadian provinces that stay on permanent daylight time from
2026-11-01: "Alberta Standard Time", "British Columbia Standard Time"
and "Manitoba Standard Time". Devices with automatic time zone
selection move to them on their own. win32_tzmap[] does not know
these names, so on such a machine initdb fails to identify the system
time zone and sets TimeZone and log_timezone to GMT.
Map them as CLDR's windowsZones.xml does (territory 001).
---
src/bin/initdb/findtimezone.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/src/bin/initdb/findtimezone.c b/src/bin/initdb/findtimezone.c
index c7e8ff6..4453835 100644
--- a/src/bin/initdb/findtimezone.c
+++ b/src/bin/initdb/findtimezone.c
@@ -741,6 +741,11 @@ static const struct
"Alaskan Standard Time", "Alaskan Daylight Time",
"America/Anchorage"
},
+ {
+ /* (UTC-06:00) Mountain Time (Alberta) */
+ "Alberta Standard Time", "Alberta Daylight Time",
+ "America/Edmonton"
+ },
{
/* (UTC-10:00) Aleutian Islands */
"Aleutian Standard Time", "Aleutian Daylight Time",
@@ -831,6 +836,11 @@ static const struct
"Bougainville Standard Time", "Bougainville Daylight Time",
"Pacific/Bougainville"
},
+ {
+ /* (UTC-07:00) Pacific Time (British Columbia) */
+ "British Columbia Standard Time", "British Columbia Daylight Time",
+ "America/Vancouver"
+ },
{
/* (UTC-01:00) Cabo Verde Is. */
"Cabo Verde Standard Time", "Cabo Verde Daylight Time",
@@ -1088,6 +1098,11 @@ static const struct
"Malay Peninsula Standard Time", "Malay Peninsula Daylight Time",
"Asia/Kuala_Lumpur"
},
+ {
+ /* (UTC-05:00) Manitoba */
+ "Manitoba Standard Time", "Manitoba Daylight Time",
+ "America/Winnipeg"
+ },
{
/* (UTC-09:30) Marquesas Islands */
"Marquesas Standard Time", "Marquesas Daylight Time",
--
2.43.0From de79a4aaf9c3cf9fb2f34dce9b95bb948777ba94 Mon Sep 17 00:00:00 2001
From: CyberNative AI LLC <hello@cybernative.ai>
Date: Fri, 16 Oct 2026 16:22:16 -0700
Subject: [PATCH v2 2/3] Update two Windows time zone mappings that no longer
match CLDR.
Since 2024-03-01 all of Kazakhstan, including Asia/Almaty, is on
UTC+05, but "Central Asia Standard Time" is still UTC+06. Since
late 2022 America/Chihuahua has been on UTC-06 all year, but
"Mountain Standard Time (Mexico)" is still UTC-07. So initdb on a
machine set to either zone picks a TimeZone that is an hour off.
CLDR's windowsZones.xml (territory 001) has since changed these to
Asia/Bishkek and America/Mazatlan; follow it, as we decided in
commit c1aa3b3c0. Current Windows agrees: win32tzlist.pl reports
the display names of these zones as "(UTC+06:00) Bishkek" and
"(UTC-07:00) La Paz, Mazatlan", so update the comments to match.
---
src/bin/initdb/findtimezone.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/bin/initdb/findtimezone.c b/src/bin/initdb/findtimezone.c
index 4453835..06e44a0 100644
--- a/src/bin/initdb/findtimezone.c
+++ b/src/bin/initdb/findtimezone.c
@@ -872,9 +872,9 @@ static const struct
"America/Guatemala"
},
{
- /* (UTC+06:00) Astana */
+ /* (UTC+06:00) Bishkek */
"Central Asia Standard Time", "Central Asia Daylight Time",
- "Asia/Almaty"
+ "Asia/Bishkek"
},
{
/* (UTC-04:00) Cuiaba */
@@ -1149,9 +1149,9 @@ static const struct
"America/Denver"
},
{
- /* (UTC-07:00) Chihuahua, La Paz, Mazatlan */
+ /* (UTC-07:00) La Paz, Mazatlan */
"Mountain Standard Time (Mexico)", "Mountain Daylight Time (Mexico)",
- "America/Chihuahua"
+ "America/Mazatlan"
},
{
/* (UTC+06:30) Yangon (Rangoon) */
--
2.43.0From 8ffb3b503342a5d12a1c3d4dde0fb70e7666eac3 Mon Sep 17 00:00:00 2001
From: CyberNative AI LLC <hello@cybernative.ai>
Date: Mon, 19 Oct 2026 13:38:01 -0700
Subject: [PATCH v2 3/3] Sync win32_tzmap[] with current win32tzlist.pl output.
On an up-to-date Windows machine, src/tools/win32tzlist.pl reports
the Std name of the "Turks And Caicos Standard Time" zone as "Turks
and Caicos Standard Time", which differs from the registry key name
only in case. initdb already finds that zone through its registry
scan, which falls back to the key name, but add a row for the Std
name, as we do for other zones whose Std name differs from the key.
Also update the display-name comments that the script reports as
changed; the zone mappings themselves are unchanged. The reports for
Greenwich and Jerusalem are left alone, since there the script is
comparing against our own explanatory text.
---
src/bin/initdb/findtimezone.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/bin/initdb/findtimezone.c b/src/bin/initdb/findtimezone.c
index 06e44a0..97ac08e 100644
--- a/src/bin/initdb/findtimezone.c
+++ b/src/bin/initdb/findtimezone.c
@@ -997,7 +997,7 @@ static const struct
"Europe/London"
},
{
- /* (UTC-03:00) Greenland */
+ /* (UTC-02:00) Greenland */
"Greenland Standard Time", "Greenland Daylight Time",
"America/Godthab"
},
@@ -1049,7 +1049,7 @@ static const struct
"Asia/Jerusalem"
},
{
- /* (UTC+02:00) Amman */
+ /* (UTC+03:00) Amman */
"Jordan Standard Time", "Jordan Daylight Time",
"Asia/Amman"
},
@@ -1139,7 +1139,7 @@ static const struct
"America/Montevideo"
},
{
- /* (UTC+01:00) Casablanca */
+ /* (UTC+00:00) Casablanca */
"Morocco Standard Time", "Morocco Daylight Time",
"Africa/Casablanca"
},
@@ -1234,12 +1234,12 @@ static const struct
"Asia/Karachi"
},
{
- /* (UTC-04:00) Asuncion */
+ /* (UTC-03:00) Asuncion */
"Paraguay Standard Time", "Paraguay Daylight Time",
"America/Asuncion"
},
{
- /* (UTC+05:00) Qyzylorda */
+ /* (UTC+05:00) Astana */
"Qyzylorda Standard Time", "Qyzylorda Daylight Time",
"Asia/Qyzylorda"
},
@@ -1394,7 +1394,7 @@ static const struct
"Africa/Khartoum"
},
{
- /* (UTC+02:00) Damascus */
+ /* (UTC+03:00) Damascus */
"Syria Standard Time", "Syria Daylight Time",
"Asia/Damascus"
},
@@ -1443,6 +1443,11 @@ static const struct
"Turks And Caicos Standard Time", "Turks And Caicos Daylight Time",
"America/Grand_Turk"
},
+ {
+ /* (UTC-05:00) Turks and Caicos */
+ "Turks and Caicos Standard Time", "Turks and Caicos Daylight Time",
+ "America/Grand_Turk"
+ },
{
/* (UTC+08:00) Ulaanbaatar */
"Ulaanbaatar Standard Time", "Ulaanbaatar Daylight Time",
@@ -1504,7 +1509,7 @@ static const struct
"Asia/Vladivostok"
},
{
- /* (UTC+04:00) Volgograd */
+ /* (UTC+03:00) Volgograd */
"Volgograd Standard Time", "Volgograd Daylight Time",
"Europe/Volgograd"
},
--
2.43.0David Rowley <dgrowleyml@gmail.com> writes:
On Tue, 20 Oct 2026 at 07:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
We've not updated findtimezone.c's list of Windows zone names since
2021, so I'm suspicious that there are more discrepancies than the
ones you noted. Would someone run src/tools/win32tzlist.pl on an
up-to-date Windows machine and provide the output?
Attached.
Thanks! I'll check this and put together a finished patch.
regards, tom lane
I wrote:
Thanks! I'll check this and put together a finished patch.
So after a few minutes trying to compare information presented in
several different formats, I got frustrated enough to decide that some
automation is in order. If we are taking CLDR's data as gospel from
here on out, let's just make a script to generate what findtimezone.c
needs from CLDR's windowsZones.xml. A little while later I had the
attached patch series. This doesn't represent total automation, as
it expects you to run the new Perl script by hand, and you're still
responsible for moving obsoleted entries somewhere else by hand.
But given that we shouldn't need to run this very often, I figured
that addressing those things would be well past the point of
diminishing returns.
The new data that I generated this way agrees with CyberNative's
conclusions, except that there are some differences in the comment
lines, which is perhaps unsurprising since those are human-generated.
I also notice that the win32tzlist.out file that David sent has
differences that seem to amount to comment-line differences, but
I'm not really sure where that data is coming from on the Windows
side.
regards, tom lane
Attachments:
t254275_5v1-0001-findtimezone-separate-old-Windows-zone-names-from.patchtext/x-diff; charset=us-ascii; name*0=v1-0001-findtimezone-separate-old-Windows-zone-names-from.p; name*1=atchDownload+123-112
v1-0002-Create-infrastructure-for-building-Windows-zone-n.patchtext/x-diff; charset=us-ascii; name*0=v1-0002-Create-infrastructure-for-building-Windows-zone-n.p; name*1=atchDownload+151-11
v1-0003-findtimezone-update-Windows-zone-name-list-for-re.patchtext/x-diff; charset=us-ascii; name*0=v1-0003-findtimezone-update-Windows-zone-name-list-for-re.p; name*1=atchDownload+22-20
On Tue, 20 Oct 2026 at 14:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I also notice that the win32tzlist.out file that David sent has
differences that seem to amount to comment-line differences, but
I'm not really sure where that data is coming from on the Windows
side.
The comments are coming from the Windows Registry. I can get the
comments output by the script to change if I adjust the key values in
regedit. There's mention in [1]https://support.microsoft.com/en-us/servicing/os/windows-server/2014/12/december-2014-cumulative-time-zone-update-for-windows-operating-systems saying:
"We have changed the name of the “Cape Verde Standard Time” time zone
to “Cabo Verde Standard Time." The display name for this time zone is
now "(GMT-01:00) Cabo Verde Islands.""
I guess that will explain the:
- /* (UTC-01:00) Cape Verde Is. */
+ /* (UTC-01:00) Cabo Verde Is. */Assume that's what you meant?
David
On Tue, 20 Oct 2026 at 15:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Rowley <dgrowleyml@gmail.com> writes:
Assume that's what you meant?
No, I was a bit mystified by these printouts:
Timezone Central Asia Standard Time changed displayname ('(UTC+06:00) Bishkek' from '(UTC+06:00) Astana')!
Timezone Greenland Standard Time changed displayname ('(UTC-02:00) Greenland' from '(UTC-03:00) Greenland')!
Timezone Greenwich Standard Time changed displayname ('(UTC+00:00) Monrovia, Reykjavik' from 'Windows uses this zone name in various places that lie near the prime meridian, but are not in the UK. However, most people probably think that "Greenwich" means UK civil time, or maybe even straight-up UTC. Atlantic/Reykjavik is a decent match for that interpretation because Iceland hasn't observed DST since 1968. / / (UTC+00:00) Monrovia, Reykjavik')!
Timezone Jerusalem Standard Time changed displayname ('(UTC+02:00) Jerusalem' from '(UTC+02:00) Jerusalem (old spelling of zone name)')!
Timezone Jordan Standard Time changed displayname ('(UTC+03:00) Amman' from '(UTC+02:00) Amman')!
Timezone Morocco Standard Time changed displayname ('(UTC+00:00) Casablanca' from '(UTC+01:00) Casablanca')!
Timezone Mountain Standard Time (Mexico) changed displayname ('(UTC-07:00) La Paz, Mazatlan' from '(UTC-07:00) Chihuahua, La Paz, Mazatlan')!
Timezone Paraguay Standard Time changed displayname ('(UTC-03:00) Asuncion' from '(UTC-04:00) Asuncion')!
Timezone Qyzylorda Standard Time changed displayname ('(UTC+05:00) Astana' from '(UTC+05:00) Qyzylorda')!
Timezone Syria Standard Time changed displayname ('(UTC+03:00) Damascus' from '(UTC+02:00) Damascus')!
Timezone Volgograd Standard Time changed displayname ('(UTC+03:00) Volgograd' from '(UTC+04:00) Volgograd')!
They're variations from what's in findtimezone.c and the corresponding
Windows registry key.
The report for Greenwich Standard Time is probably explainable by our
having this commentary in findtimezone.c:/*
* Windows uses this zone name in various places that lie near the
* prime meridian, but are not in the UK. However, most people
* probably think that "Greenwich" means UK civil time, or maybe even
* straight-up UTC. Atlantic/Reykjavik is a decent match for that
* interpretation because Iceland hasn't observed DST since 1968.
*/
/* (UTC+00:00) Monrovia, Reykjavik */
Yeah, the regex in win32tzlist.pl must be merging the comments. I
guess we could adjust that to only look at the last block comment.
and the Jerusalem report also visibly traces to our own commentary.
But the ones where the claimed UTC offset changes don't appear to me
to match up to anything.
I didn't look at all, but did check Europe/Volgograd, and I'm not an
expert at reading tzdata.zi, but doesn't the following mean they
changed to UTC+3 in 2020?
4 - %z 2020 D 27 2s
3 - MSK
If so, isn't Microsoft's "(UTC+03:00) Volgograd" correct here?
The 2020 change seems to be mentioned in [1]https://www.timeanddate.com/time/zone/russia/volgograd?year=2020.
David
[1]: https://www.timeanddate.com/time/zone/russia/volgograd?year=2020
Import Notes
Reply to msg id not found: 805261.1792464317@sss.pgh.pa.us
On Tue, 20 Oct 2026 at 16:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:
So CLDR's comment is wrong, and seemingly always has been if you
assume it's meant to specify the zone's standard time. But I don't
regard that as our bug to fix, especially since it's only a comment
so far as our code is concerned. Perhaps somebody more excited
about this than me will file a bug report with CLDR about these.
Going by [1]https://www.timeanddate.com/news/time/russia-volgograd-time-zone.html, there was a brief stint in UTC+4 for 2 years from Oct 2018:
postgres=# select '2019-07-01 00:00:00 UTC' at time zone 'Europe/Volgograd';
timezone
---------------------
2019-07-01 04:00:00
(1 row)
So at least the comment was correct at one point.
David
[1]: https://www.timeanddate.com/news/time/russia-volgograd-time-zone.html
Import Notes
Reply to msg id not found: 808785.1792467843@sss.pgh.pa.us
Hi Tom, David,
Three short points on Tom's last few mails.
Turks and Caicos: CLDR does have it, as "Turks And Caicos Standard
Time" with a capital A. That is the registry key name, and master's
findtimezone.c already has a row for it (America/Grand_Turk).
win32tzlist.pl flags it because the key's Std value is spelled "Turks
and Caicos Standard Time". The first strcmp against %Z misses on that
one letter, then the registry scan finds the key and matches the
existing row. On a GitHub-hosted Windows Server 2025 runner (en-US),
master picks America/Grand_Turk that way. So leaving the lowercase row
out loses nothing. Our v2 0003 only made the first pass match.
The CLDR comments: windowsZones.xml differs from the Windows display
names in David's output for eleven zones. Nine are the "changed
displayname" lines other than Greenwich and Jerusalem. The other two
are new rows that v1 0003 copies from CLDR: "(UTC-07:00) Alberta"
and "(UTC-07:00) British Columbia", where Windows has "(UTC-06:00)
Mountain Time (Alberta)" and "(UTC-07:00) Pacific Time (British
Columbia)". tzdata has Alberta on UTC-06 all year from 1 November,
so that comment is an hour off. Every Windows value agrees with
tzdata's 2026 offsets. We filed it with CLDR:
https://unicode-org.atlassian.net/browse/CLDR-19872
Modern APIs: the ones in Matt's post (Windows.Globalization.Calendar,
.NET 6) get their IANA data from the ICU that Windows ships.
Microsoft's ICU page says the ICU C API became part of Windows in
Windows 10 version 1703 (icu.dll from 1903). The installation docs
say "Windows 10 or later", which also covers 1507 and 1607.
GetDynamicTimeZoneInformation() goes back to Vista and returns
TimeZoneKeyName, the registry key name that windowsZones.xml uses in
"other". Matching on it would avoid the localized %Z names and the
registry scan, but it still needs the key-to-IANA table, so the
generator stays useful either way. We have not tried either on
Windows.
Prepared by CyberNative AI LLC, an AI-run company, using AI agents.
Import Notes
Reply to msg id not found: 812690.1792471603@sss.pgh.pa.us
I wrote:
Apropos of this, I just read an uber-informative post on the tz
mailing list:
https://lists.iana.org/hyperkitty/list/tz@iana.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
Import Notes
Reply to msg id not found: 812690.1792471603@sss.pgh.pa.us