tzdata 2026e: on 1 November, containers with old time-zone data put four Canadian clocks an hour off

OCImend · 2026-10-14 · news

Short answer

In 2026 British Columbia (UTC−07), Alberta (UTC−06), the Northwest Territories (UTC−06) and Manitoba (UTC−05) moved to permanent time, added to the tz database in releases 2026b to 2026e. The tz database applies all four on 1 November 2026 at 02:00, the night the rest of North America falls back. Anything that computes local time from older tz data (a container image, a Go binary with embedded data, a JVM, a host) will fall back anyway and be an hour wrong in Vancouver, Edmonton, Yellowknife and Winnipeg. The fix is tzdata 2026e or newer in every copy the software actually reads, starting with the image.

Flash · tz database release 2026e (29 September 2026) completes Canada's move to permanent time. Effective in the data: Sunday 1 November 2026, 02:00 local.

What changed, and in which release

tz release	Where	Zone	From 1 November 2026
2026b	British Columbia	`America/Vancouver`	stays on UTC−07 (no fall back)
2026c	Alberta	`America/Edmonton`	stays on UTC−06 (no fall back)
2026d	Northwest Territories	`America/Inuvik` (Yellowknife follows `America/Edmonton`)	stays on UTC−06
2026e	Manitoba	`America/Winnipeg`	stays on UTC−05 (no fall back)
2026c	Morocco, Western Sahara	`Africa/Casablanca`, `Africa/El_Aaiun`	already in force: permanent UTC+00 since 20 September

Time-zone abbreviations change too: with new data, Vancouver shows MST, Edmonton and Inuvik CST, and Winnipeg EST from 1 November. Code that parses or maps abbreviations (log parsers, reports, "CST means UTC−06" lookups) needs checking as well as the offsets.

The legal dates are earlier (British Columbia from 9 March, Alberta from 18 June, Manitoba from 31 October), but clocks only start to differ when the old rules would have fallen back, so the tz database models every Canadian change on 1 November. That is also the first day stale data shows wrong times. You need 2026e or newer to be right everywhere: an image on 2026c is right in Vancouver and Edmonton but an hour off in Winnipeg.

Live: images OCImend has scanned

Loading the numbers…

What goes wrong with old data

011 Nov, 02:00old rules fall back
02Local timeone hour behind in 4 regions
03Scheduleslocal-time jobs run an hour late
04Recordslogs, invoices, bookings show the wrong hour

Displayed and stored local times are an hour off for users in those zones: appointments, shift rosters, receipts, report cut-offs, "today" boundaries.
Schedules in local time (cron with a time zone, Kubernetes CronJobs with timeZone, schedulers in Java, Go, Python) fire an hour early or late.
Two services disagree when one has new data and the other old: the same instant is rendered differently.
Timestamps kept in UTC are unaffected: the error is in converting them to and from local time.

Where your time-zone data actually comes from

Runtime / layer	Reads its tz data from	Fix
Container image (any)	its own `/usr/share/zoneinfo`, not the host's	upgrade the `tzdata` package in the image and rebuild
Go	`$ZONEINFO`, then the system zoneinfo, then `$GOROOT/lib/time/zoneinfo.zip`, then `time/tzdata` if imported	add system tzdata to the image, or rebuild with a Go release that embeds 2026e
Java	the JDK's own `tzdb.dat`	update the JDK, or apply the vendor's time-zone updater to the JDK in the image
Node.js	ICU data built into Node	a Node.js release with updated ICU time-zone data
Python	`zoneinfo`: system tzdata, else the `tzdata` package; `pytz`: its own copy	upgrade the OS tzdata, and `tzdata` / `pytz` to 2026.5 (= 2026e) or newer
PostgreSQL	the system tzdata, or its own copy when built with it	the minor release that carries 2026e, or the OS package
MySQL / MariaDB	time-zone tables loaded from the system zoneinfo	upgrade tzdata, then reload with `mysql_tzinfo_to_sql`
Host (VM, node)	`/usr/share/zoneinfo` of the OS	upgrade tzdata; restart long-running services that cached the rules

The trap in containers: patching your nodes fixes nothing inside images. Each image carries the tzdata it was built with, often years old, and distroless or scratch images with Go programs carry none at all, so the program uses whatever its Go toolchain embedded, or fails to load the zone.

Check an image in one line

Run these inside the image (a one-off container of it, or kubectl exec into a running pod):

# Should print -1 day, 19:00:00 (UTC−05). With old data: -1 day, 18:00:00 (UTC−06).
python3 -c "from zoneinfo import ZoneInfo; from datetime import datetime; print(datetime(2026,11,2,12,tzinfo=ZoneInfo('America/Winnipeg')).utcoffset())"

# Without Python: the release the image's time-zone data says it is
head -1 /usr/share/zoneinfo/tzdata.zi

Or paste the image into OCImend: every scan now reports which tz database release the image carries, which of these changes it misses, and the exact command to fix it.

The fix, layer by layer

# Debian / Ubuntu images
RUN apt-get update && apt-get install -y --only-upgrade tzdata && rm -rf /var/lib/apt/lists/*
# Alpine / Wolfi
RUN apk upgrade --no-cache tzdata
# RHEL / UBI / Fedora
RUN dnf -y upgrade tzdata   # microdnf on minimal images
# Go in scratch/distroless: ship the data the program reads
COPY --from=docker.io/library/debian:stable-slim /usr/share/zoneinfo /usr/share/zoneinfo

Your distribution must have published its 2026e package first; check the release your image actually got after the build (the line above), not the command you ran.

How OCImend handles it

01Scantz release of every copy in the image
02Flagwhich regions it gets wrong, from when
03CVE-fixed buildrefreshes tzdata in the same step
04Rescanshows the release the image now has

When OCImend builds a CVE-fixed image and the image's tzdata misses these changes, the time-zone package is upgraded in the same step as the security fixes, to the newest release the distribution offers, and the rescanned image shows the release it ended up with.

Next: part 2, checking Go, Java, Node.js and Python by hand, with real outputs, and the free online check.

Check my image's time-zone data →

Questions

Do I need to change my servers or my containers?

Both, separately. A container reads the time-zone data inside its own image, so updating hosts does not fix images; rebuild images with tzdata 2026e or newer.

Which release do I need?

2026e or newer. 2026b covers British Columbia, 2026c Alberta and Morocco, 2026d the Northwest Territories, 2026e Manitoba.

When does it start to matter?

Sunday 1 November 2026 at 02:00 local time, when old data falls back an hour and the new data does not. Morocco's change has applied since 20 September 2026.

My Go program runs in a scratch image. Is it affected?

It uses the data Go embedded (time/tzdata) or its toolchain's zoneinfo.zip, or fails to load the zone. Add /usr/share/zoneinfo from a current image, or rebuild with a Go release that carries 2026e.

Are UTC timestamps affected?

No. Only conversions between UTC and local time in those zones.