Skip to content

fix(tz): map the Windows zones CLDR already names - #1059

Open
Cherith1222 wants to merge 2 commits into
python-pendulum:masterfrom
Cherith1222:fix/1058-windows-canada-zones
Open

Cherith1222 wants to merge 2 commits into
python-pendulum:masterfrom
Cherith1222:fix/1058-windows-canada-zones

Conversation

@Cherith1222

Copy link
Copy Markdown

Why

On Windows, pendulum.now() looks up TimeZoneKeyName in a fixed table and raises LookupError when the name is missing. CLDR's territory 001 rows already name seven of those zones, including the Canada zones Windows added in October 2026. Two older rows also point at zones that no longer share the Windows offset.

What changed

  • Add British Columbia, Alberta, Manitoba, Yukon, Qyzylorda, South Sudan, and Volgograd.
  • Point Central Asia Standard Time at Asia/Bishkek, and Mountain Standard Time (Mexico) at America/Mazatlan.

Scope

  • Covers the Windows name table used for the local timezone.
  • Leaves the Europe/Kyiv and Etc/GMT spellings as they are.
  • Does not raise the tzdata requirement. Winnipeg's offset after 1 November 2026 still depends on a current tzdata.

Tradeoffs

Keeping Asia/Almaty and America/Chihuahua would preserve offsets that are an hour away from the Windows zone. This table already follows CLDR's territory 001 row for the other names.

Blast Radius

pendulum.now() on Windows reads this table. Machines on the new Canada zones stop raising. Machines on Central Asia Standard Time or Mountain Standard Time (Mexico) follow the CLDR zone.

Verification

  • Before the table change, the nine new mapping cases failed. Seven were KeyError. Central Asia was Asia/Almaty, and Mountain Standard Time (Mexico) was America/Chihuahua.
  • After the change, py -3.13 -m pytest tests/tz/test_local_timezone.py -q reported 11 passed and 3 skipped. The skipped tests are the Unix-only cases.
  • On this Windows machine the registry lookup still returns Asia/Taipei.

Fixes #1058

Drafted with Cursor.

@Muguett-DBY Muguett-DBY left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checked ab35f7d against the pinned CLDR c4bb2c199c data. All 142 territory-001 IDs are covered. The nine changed entries match CLDR, and the two existing alias spellings retain equivalent offsets across the dates checked.

On native Windows/Python 3.12, I exercised pendulum.now() for every mapped ID, with and without a NUL tail, by substituting EnumValue results while using real registry handles. The suffix fallback and unknown-name error also behave as expected. No registry values or OS settings were changed.

With tzdata 2026.5, all 710 CLDR offset comparisons pass on each OS, including dates after the Canadian change. The full suite passes on Windows and Linux in both pure-Python and Rust-extension modes with the lockfile's dateutil 2.9.0.post0. Restoring only the base mapping makes nine of the ten mapping tests fail; restoring this head passes all ten. Validation run.

Fresh dateutil 3.0.0 exposes an unrelated existing fixture failure on unchanged master too; it does not come from this table change. I've kept the test-only correction separate in #1072.

AI-assisted review with Codex. This verifies mapping and lookup behavior; it does not claim to test Windows automatic timezone selection or the October Windows update itself.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

pendulum.now() raises LookupError on Windows' new Canada time zones

2 participants