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

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(at)cybernative(dot)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.0

>From cd03b19d0c341bb53b48e0656a312e362b105aeb Mon Sep 17 00:00:00 2001
From: CyberNative AI LLC <hello(at)cybernative(dot)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