Canada's 1 November 2026 clock change that isn't: is your software still falling back?

Short answer: British Columbia, Alberta, the Northwest Territories (Inuvik) and Manitoba have moved to one offset all year, so their clocks do not go back at 2:00 on Sunday 1 November 2026. The time zone database (IANA tzdb) has this since releases 2026b–2026e. Software that carries its own older copy of that database will still fall back and show these zones one hour behind from that moment: bookings, reminders, timesheets, cron jobs and logs. PHP 8.3 and older, Node.js older than 24.22.1 / 22.23.4, Sequelize 6 (moment-timezone 0.5) and Go programs without system time zone files are affected. Check yours below.

What changes on 1 November 2026

Offsets computed with tzdb 2026e. Toronto, Montreal and the rest of Canada fall back as usual.

Check this browser

Check and fix your software

PHP · Node.js · Sequelize 6 and moment-timezone · Python · Go · MySQL, MariaDB and PostgreSQL · Servers, containers, Java and phones

PHP

PHP uses the time zone database compiled into it, not the operating system's, unless your distribution patched that out. Checked on 28 October 2026: PHP 8.4 and 8.5 ship 2026.5 (2026e, correct); PHP 8.3 ships 2026.1, PHP 8.2 2024.2 and PHP 8.1 2023.3, so all three still fall back for these zones (we confirmed PHP 8.2 shows Vancouver at -08:00 on 2 November).

Check:

php -r 'echo timezone_version_get(), PHP_EOL; $d = new DateTime("2026-11-02 12:00 UTC"); $d->setTimezone(new DateTimeZone("America/Winnipeg")); echo $d->format("H:i P"), PHP_EOL;'

Correct: 07:00 -05:00. If you see 06:00 -06:00, PHP's data is too old. A version of 0.system means your PHP reads the operating system's files: update the OS tzdata package instead.

Fix, any one of:

1. Move to PHP 8.4 or 8.5.
2. Install the up-to-date database as an extension, which replaces the built-in one: pecl install timezonedb, add extension=timezonedb to php.ini, restart PHP-FPM or Apache, and check that timezone_version_get() shows 2026.5. Official Docker images: RUN pecl install timezonedb && docker-php-ext-enable timezonedb.
3. Shared hosting: ask your host to load the timezonedb extension or move your site to PHP 8.4.

WordPress shows dates with PHP, so WordPress sites in these provinces on PHP 8.3 or older will show post times, scheduled posts and WooCommerce order times an hour off.

Sources: php-src: bundled timezonedb.h on the PHP-8.3 branch (2026.1); PECL timezonedb (2026.5)

Node.js

Official Node.js builds carry their own time zone data in ICU, used by Intl, toLocaleString and libraries built on them (Luxon, date-fns-tz, Day.js timezone). The full set of 2026 changes (2026e) arrived in Node 24.22.1 and 22.23.4 (21 October 2026) and 26.11.0 (7 October). Node 24.20.0 and 22.23.3 have 2026c (BC and Alberta only); Node 24.16 had 2026b (BC only). Node 20 is end of life: its last time zone update was 2025c, so it is wrong for all four zones. Node 24.19.0 shows Edmonton and Winnipeg an hour off (we checked).

Check:

node -p "process.versions.tz + ' ' + new Date(Date.UTC(2026,10,2,12)).toLocaleString('en-CA', {timeZone: 'America/Winnipeg', timeZoneName: 'longOffset'})"

Correct: 2026e and GMT-05:00.

Fix: upgrade to Node 24.22.1+, 22.23.4+ or 26.11.0+, and move Node 20 apps to 22 or 24. Node built against the system ICU (some Linux packages) uses the OS's ICU data: update the OS packages.

Sources: Node.js v24 changelog (24.22.1: timezone 2026e); Node.js v22 changelog (22.23.4: timezone 2026e); Node.js v20 changelog (last tz update 2025c)

Sequelize 6 and moment-timezone

Sequelize 6 (latest 6.37.8) depends on moment-timezone ^0.5.43. The 0.5 line ends at 0.5.48, whose data is 2025b; the 2026 data (2026e) is only in moment-timezone 0.6.5. Apps that pass an IANA name as Sequelize's timezone option (for example America/Edmonton) convert MySQL and MariaDB dates with that old data, so stored and displayed times can shift an hour for these zones. Any other code that uses moment-timezone 0.5 is affected the same way.

Check: npm ls moment-timezone (0.5.x = old data).

Fix: force the new version for the whole tree, then test your date handling:

// package.json (npm 8.3+)
"overrides": { "moment-timezone": "0.6.5" }
// yarn: "resolutions": { "moment-timezone": "0.6.5" }   pnpm: "pnpm": { "overrides": { "moment-timezone": "0.6.5" } }

Run npm install and npm ls moment-timezone again. 0.6 is a new minor line, so run your tests that touch dates before deploying.

Sources: npm: sequelize 6.37.8 depends on moment-timezone ^0.5.43; npm: moment-timezone (0.5.48 has 2025b data, 0.6.5 has 2026e)

Python

zoneinfo reads the operating system's files on Linux and macOS and the tzdata package on Windows (or when no system files exist, as in slim containers). pytz carries its own copy. Both tzdata and pytz 2026.5 have the new rules.

Check:

python -c "from zoneinfo import ZoneInfo; from datetime import datetime, timezone; print(datetime(2026,11,2,12,tzinfo=timezone.utc).astimezone(ZoneInfo('America/Winnipeg')))"

Correct: 2026-11-02 07:00:00-05:00.

Fix: pip install -U tzdata pytz (and unpin old versions in requirements), and update the OS tzdata package on servers and in container images.

Sources: PyPI: tzdata 2026.5; PyPI: pytz 2026.5

Go

Go reads the system's zoneinfo files when they exist. Programs in scratch or distroless images without zoneinfo, programs that embed time/tzdata (or build with -tags timetzdata), and Go on Windows use the copy shipped with Go: Go 1.27 has 2026c (missing the NWT and Manitoba changes) and Go 1.26 has 2025c (missing all four). That includes container schedulers and tools written in Go that run in minimal images.

Fix: install the OS time zone package in the image (apk add tzdata, apt-get install tzdata) or point ZONEINFO at an up-to-date zoneinfo.zip, then rebuild. Check with a one-line program that prints time.Date(2026, 11, 2, 12, 0, 0, 0, time.UTC).In(loc) for America/Winnipeg: it must show -0500.

Sources: Go: lib/time/update.bash (Go 1.27: 2026c, Go 1.26: 2025c)

MySQL, MariaDB and PostgreSQL

MySQL/MariaDB named time zones come from tables you load from the operating system's files; they do not update themselves.

SELECT CONVERT_TZ('2026-11-02 12:00:00', 'UTC', 'America/Winnipeg');

Correct: 07:00:00. If it shows 06:00:00, update the OS tzdata package, reload with mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql and restart the server. NULL means the tables were never loaded.

PostgreSQL on most Linux packages reads the system files; Windows installers and some builds carry their own copy.

SELECT timestamptz '2026-11-02 12:00+00' AT TIME ZONE 'America/Winnipeg';

Correct: 2026-11-02 07:00:00. If not, update the OS package (or PostgreSQL itself) and restart.

Sources: MySQL: Staying current with time zone changes

Servers, containers, Java and phones

Linux servers and containers: update the tzdata package, and rebuild container images: an image keeps the time zone files it was built with. Check with zdump -v -c 2026,2027 America/Winnipeg: with current data the 1 November 2026 lines keep gmtoff=-18000 (-05:00, shown as EST); old data switches to CST with gmtoff=-21600.

Java carries its own database. Check with jshell: java.time.ZonedDateTime.parse("2026-11-02T12:00Z").withZoneSameInstant(java.time.ZoneId.of("America/Winnipeg")) must end in -05:00; if not, update the JDK or apply your JDK vendor's time zone updater.

Phones, laptops, POS terminals and other devices get the rules from system updates: install them, and check devices that don't update automatically.

Questions

Do these provinces still change clocks in March?

No. Their 8 March 2026 spring forward was the last one; they stay on that offset all year. IANA models the change at 2:00 on 1 November 2026 for technical reasons (a workaround for CLDR), which is when the difference shows up in software.

Why does my app now show MST in Vancouver, CST in Edmonton and EST in Winnipeg?

That is the new abbreviation for the same offset: the database names -07:00 MST, -06:00 CST and -05:00 EST. Users may find the label surprising; the time is correct. If you show abbreviations, consider showing the offset or the city instead.

Which other places are affected?

Saskatchewan (America/Regina) and Yukon (America/Whitehorse) were already on one offset all year and are unchanged. The rest of Canada (Toronto, Montreal, Halifax, St. John's) falls back as usual on 1 November.

I fixed it after 1 November. Are stored times wrong?

Times stored in UTC are fine; only their display was off. Times converted to local time with old data and stored as local time (or scheduled with it) between 1 November and your fix may be an hour off: find them by date and correct them.

Sources

• IANA tz database NEWS (releases 2026b–2026e)

Versions checked 28 October 2026 against each project's own files. Independent guide, not affiliated with IANA or any vendor named.