Wrong time after Canada's November 1 time change: which runtimes are still an hour off, and the tested fixes

What changes on 1 November

Each province or territory moves to permanent time and stops changing clocks twice a year. The IANA database models all four changes as taking effect on 1 November 2026 at 02:00 local time. Before that date every version of the data gives the same answer; after it, old data is one hour off.

2026c also moved Morocco to permanent UTC+00 from 20 September 2026 (Africa/Casablanca, Africa/El_Aaiun). Data older than 2026c shows UTC+01 there now.

Which runtimes are still wrong

This covers the runtime's own copy of the data, not the operating system's. "Wrong from 1 Nov" assumes you install every release available before then.

Already fixed once you update: pytz 2026.5, Ruby tzinfo-data 1.2026.5, moment-timezone 0.6.5, @js-joda/timezone 3.1.0, Joda-Time 2.15.0, and Alpine and Red Hat (UBI9, UBI10) tzdata. Each of these carries 2026e.

Fixed only where the OS has no zoneinfo: Python's zoneinfo module and Rust's jiff read the operating system's copy first. Their own 2026e data (the PyPI tzdata package 2026.5, jiff-tzdb 0.1.9) is used only where the OS has none, such as Windows or an image without tzdata. Otherwise they are as current as the OS: see Base images.

Am I affected?

Java. Print the data version inside your image or on your server. The path is $JAVA_HOME/jre/lib/tzdb.dat in a Java 8 JDK and $JAVA_HOME/lib/tzdb.dat everywhere else.

head -c 16 "$JAVA_HOME/lib/tzdb.dat" | grep -ao "20[0-9][0-9][a-z]"

Anything before 2026e means affected; 2026e means fixed. On 13 October the stock eclipse-temurin:21-jre image printed 2026b.

PHP.

php -r 'echo timezone_version_get(), "\n";'

2026.5 or later means fixed. On 13 October the official images printed 2024.2 (8.2), 2026.1 (8.3) and 2026.3 (8.4 and 8.5). PHP 8.4.27 and 8.5.12, released on 21 October, carry 2026.5; 8.3.36 and 8.2.35 keep 2026.1 and 2024.2. A .1 to .5 suffix maps to the letters a to e. 0.system means PHP uses the operating system's data, as Debian's and Ubuntu's own PHP packages do; see Base images. On Ubuntu 24.04 with its php8.3-cli package, PHP printed 0.system and Inuvik at −07:00.

Node.js.

node -p process.versions.tz

2026e or later means fixed. On 21 October the official node:24.22.1 and node:22.23.4 images, and their -alpine variants, printed 2026e and the right December offsets for Vancouver, Edmonton, Inuvik and Winnipeg. Earlier 22 and 24 releases print 2026c or older (we checked 22.23.3, 24.21.0 and 24.22.0), so Inuvik and Winnipeg are wrong on them from 1 November. Before 24.20.0 and 22.23.3 the data is older still, so Edmonton is wrong too: 24.19.0 prints 2026b, and 22.23.2 prints 2026a, which also gets Vancouver wrong.

Go. Go reads the operating system's zoneinfo first and falls back to its own copy only when none is found. A Go binary in a scratch image has no zoneinfo to read. If it was built with -tags timetzdata or imports time/tzdata, it uses the built-in copy and is affected; if not, it cannot load these zones at all. Distroless static images ship Debian's zoneinfo, and Go reads that instead: static-debian12 has 2026b, which is wrong for Edmonton, Inuvik and Winnipeg, while current static and static-debian13 images have 2026e (older digests have 2026c). A Go binary on any other OS image is exactly as current as that image's tzdata package (see Base images below).

Any language, offset check. Ask for the UTC offset on 15 December 2026. Correct answers: Edmonton −06:00, Inuvik −06:00, Winnipeg −05:00. For Java, with a JDK 11 or later on the path, run this block as it is. On Java 8, replace the last line with javac Check.java && java Check.

cat > Check.java <<'EOF'
import java.time.*;
public class Check {
  public static void main(String[] a) {
    Instant t = Instant.parse("2026-12-15T12:00:00Z");
    for (String z : new String[]{"America/Edmonton", "America/Inuvik", "America/Winnipeg", "Africa/Casablanca"})
      System.out.println(z + " " + ZoneId.of(z).getRules().getOffset(t));
  }
}
EOF
java Check.java

Stock Temurin 21.0.12 prints -07:00, -07:00, -06:00 and +01:00. After the fix, or on a build that ships 2026e such as Temurin 25.0.5, it prints -06:00, -06:00, -05:00 and Z.

Many images, or no shell? These commands need a shell inside the container, and distroless and scratch images have none. tzscan reads an image's files without running it, lists the copies of the time-zone data it recognises and gives each a verdict for 1 November. It shows which copy is used by default, not which one your program calls.

Fix: Java (Temurin, Debian OpenJDK, Corretto)

Java keeps all its time-zone rules in one file, tzdb.dat. You can build that file yourself from OpenJDK's own sources at the commit that brought in 2026e, using OpenJDK's own compiler for it, and drop it into your JDK. We publish the recipe and the expected checksum, not a binary, so you can verify what you install.

Check for an upgrade first. On Linux x64 and on macOS with Apple silicon, Temurin 17.0.21, 21.0.13 and 25.0.5 already ship 2026e. So do Amazon Corretto's 23 October releases for 8, 11, 17, 21 and 25, and the amazoncorretto images built from them. So does Debian 12's openjdk-17 security update of 23 October (17.0.21); Debian 13's OpenJDK 21 and 25 packages still had 2026b on 26 October. Upgrading is simpler than this fix. The eclipse-temurin images for 21 and 25 have carried 2026e since 29 October, and the Windows x64 builds of 21.0.13 and 25.0.5 carry it too. Use the fix for Temurin 8 and 11, for Temurin 17 on Windows, for the eclipse-temurin images for 8, 11 and 17 until they move to the October release, and for other JDKs such as Debian 13's OpenJDK. The check above tells you which one you run.

Why you can trust the result. We first used the same recipe on the commits that shipped 2026b: the output is byte-for-byte the tzdb.dat in Temurin 11, 17, 21 and 25. On the commit with 2026d it is byte-for-byte Corretto 21's file. Then we put the 2026e file into Temurin 8, 11, 17, 21 and 25 and compared every one of the 604 zones against the stock file: exactly the 18 zones named in the 2026c, 2026d and 2026e release notes changed, and nothing else.

You need git and Docker. Save this script as build-tzdb.sh. It follows OpenJDK's build rules for this file and runs offline in a container:

#!/bin/bash
# Build an OpenJDK update line's tzdb.dat exactly as its make rules do (GendataTZDB.gmk + CopyInterimTZDB.gmk).
# usage: build-tzdb.sh <git-repo-dir> <commit> <out.dat>   (needs docker + ${BUILD_IMAGE:-eclipse-temurin:21-jdk}; runs offline)
set -euo pipefail
repo=$1 rev=$2 out=$3
w=$(mktemp -d "${TMPDIR:-/tmp}/tzdb.XXXXXX"); mkdir -p "$w/tool" "$w/tzdata"
if git -C "$repo" cat-file -e "$rev:jdk/make/data/tzdata/VERSION" 2>/dev/null; then   # jdk8u layout: self-contained tool
  git -C "$repo" archive "$rev" jdk/make/data/tzdata | tar -x -C "$w/tzdata" --strip-components=4
  git -C "$repo" archive "$rev" jdk/make/src/classes/build/tools/tzdb | tar -x -C "$w/tool" --strip-components=7
else
  d=src/java.base/share/data/tzdata; git -C "$repo" cat-file -e "$rev:$d/VERSION" 2>/dev/null || d=make/data/tzdata
  git -C "$repo" archive "$rev" "$d" | tar -x -C "$w/tzdata" --strip-components=$(( $(tr -cd / <<<"$d" | wc -c) + 1 ))
  git -C "$repo" archive "$rev" make/jdk/src/classes/build/tools/tzdb | tar -x -C "$w/tool" --strip-components=7
  for f in ZoneRules ZoneOffsetTransition ZoneOffsetTransitionRule Ser; do
    git -C "$repo" show "$rev:src/java.base/share/classes/java/time/zone/$f.java" | sed -e "s/package java.time.zone/package build.tools.tzdb/" > "$w/tool/$f.java"
  done
fi
chmod -R a+rwX "$w"
docker run --rm --network none -u "$(id -u):$(id -g)" -v "$w:/w" -w /w ${BUILD_IMAGE:-eclipse-temurin:21-jdk} sh -c \
  'mkdir cls && javac -nowarn -encoding UTF-8 -d cls tool/*.java 2>&1 | grep -v "^Note" ; java -cp cls build.tools.tzdb.TzdbZoneRulesCompiler -srcdir tzdata -dstfile tzdb.dat africa antarctica asia australasia europe northamerica southamerica backward etcetera gmt jdk11_backward'
cp "$w/tzdb.dat" "$out"
echo "$(grep -v '^#' "$w/tzdata/VERSION" | grep -v '^\s*$') $(sha256sum < "$out" | cut -c1-64) $out"

Java 11, 17, 21 and 25 all use the same file. Build it from the jdk25u-dev commit 749c4eb, "8393337: (tz) Update Timezone Data to 2026e":

git clone --filter=blob:none --no-checkout --shallow-since=2026-10-01 https://github.com/openjdk/jdk25u-dev
bash build-tzdb.sh jdk25u-dev 749c4eb5856693ff9a9ae8d8d4fc77cb374fd36c tzdb-2026e.dat

It prints tzdata2026e a02e3a23d67255782b11ab81070902235ab564080f0f65ffe2a989cdaa86fe89 tzdb-2026e.dat. Building from the 2026e commits in jdk11u-dev, jdk17u-dev or jdk21u-dev gives the same checksum, and so does the lib/tzdb.dat in Temurin 17.0.21, 21.0.13 and 25.0.5 for Linux x64, in 21.0.13 for Alpine Linux x64 and in Debian 12's openjdk-17 17.0.21 package. If yours differs, don't install it.

Java 8 needs its own file, from the jdk8u-dev commit 46d5191:

git clone --filter=blob:none --no-checkout --shallow-since=2026-10-01 https://github.com/openjdk/jdk8u-dev
bash build-tzdb.sh jdk8u-dev 46d5191081489a1998575f5aa8edcef4bc76da90 tzdb-2026e-jdk8.dat

Java 8's compiler writes the zones in a different order on each run, so this file's checksum varies. Check the result with Check.java instead. To confirm the recipe for Java 8, we rebuilt the file from the jdk8u-dev commit that shipped 2026b and compared all 604 zones with Temurin 8's shipped file: they are identical.

Install it. In a container image, copy it over the original:

FROM eclipse-temurin:21-jre
COPY tzdb-2026e.dat /opt/java/openjdk/lib/tzdb.dat

In a Java 8 JDK image such as eclipse-temurin:8-jdk, copy tzdb-2026e-jdk8.dat to /opt/java/openjdk/jre/lib/tzdb.dat instead. That image has no lib/tzdb.dat, and a file copied there is never read. Run Check.java in the built image to confirm.

On a server, a JDK package update puts the old file back. It replaces tzdb.dat without a message. Debian and Ubuntu ship their OpenJDK updates through the security archive, so automatic security updates install them where those are turned on. On 14 October we copied the 2026e file into Temurin 21 from Adoptium's apt repository and into Debian's OpenJDK 25, then installed each package's next update: both were back on 2026b. Until 14 October this page said to copy the file in by hand. If you did, run the block below now, whether or not an update has already replaced your copy.

On Debian and Ubuntu, have the package manager keep your copy instead. In the directory with tzdb-2026e.dat, run:

F=$(dirname "$(dirname "$(readlink -f "$(command -v java)")")")/lib/tzdb.dat
head -c 16 "$F" | grep -ao "20[0-9][0-9][a-z]"
sudo dpkg-divert --local --rename --divert "$F.distrib" --add "$F"
sudo install -m 644 tzdb-2026e.dat "$F"

The first line finds the JDK that java runs, and the second prints its current data version. If it says there is no such file, set F to the file's full path; a Java 8 JDK keeps it in jre/lib. For another JDK on the same server, set F to its file and run the last two lines again. Then restart the Java processes. From now on, package updates write their copy to tzdb.dat.distrib and leave yours in place. We ran this block as printed with Temurin 21 and Debian's OpenJDK 25 on Debian 13 and with Ubuntu's OpenJDK 21 on Ubuntu 24.04. After each package's next update, the file was still 2026e. Running the block twice is safe.

With RPM packages, or a JDK unpacked from an archive, there is no such step. Back up the file, copy the new one in its place and restart the Java processes. After every JDK update, print the data version again and copy the file back in if it shows the old one. To roll back, restore the backup.

What changes. Offsets and instants are correct for all four provinces and territories and for Morocco. Time-zone abbreviations come from a different part of the JDK, so they stay as before: Winnipeg prints -05:00 CST and Edmonton -06:00 MST. If your output depends on those abbreviations, test it. Stock Temurin already prints -07:00 PST for Vancouver.

When to remove it. Remove the override when you move to a release that carries 2026e (from October's 17, 21 and 25 releases if built from OpenJDK's tags, January 2027 for 8 and 11), so it doesn't hold back later data updates. Where you used the block above, updates can't change the file until you do, including January's. This removes it and puts back the copy from the package version you have installed, which is also how to roll back:

sudo rm "$F" && sudo dpkg-divert --local --rename --remove "$F"

Other options. Red Hat's UBI OpenJDK images already carry 2026e through the OS tzdata-java package, so switching base image is a valid fix. OpenJDK's tracker also lists 2026e for Oracle's own out-of-band JDK updates; we didn't check those builds, Oracle's TZUpdater tool or its licence terms.

Fix: PHP 8.2, 8.3, and 8.4/8.5 before 8.4.27/8.5.12

The PECL timezonedb extension replaces PHP's built-in data. Version 2026.5 carries 2026e. In the official Debian-based images:

FROM php:8.3-cli
RUN apt-get update && apt-get install -y $PHPIZE_DEPS \
 && pecl install timezonedb-2026.5 \
 && docker-php-ext-enable timezonedb

We tested this on 8.2.34, 8.3.35 and 8.4.26: afterwards timezone_version_get() prints 2026.5 and all four Canadian zones are correct. On PHP 8.4 and 8.5 you can instead update to 8.4.27 or 8.5.12, released on 21 October, which carry 2026e.

Fix: Go in scratch and distroless static-debian12 images

A current gcr.io/distroless/static or static-debian13 image needs no fix. Distroless moved them to Debian's 2026e on 23 October. On 24 October a Go 1.27.3 binary in the current images gave Edmonton −06, Inuvik −06 and Winnipeg −05, with or without -tags timetzdata. If you pin an older digest, move to a current one.

For scratch and static-debian12: Go uses the operating system's zoneinfo before its built-in copy, so give the image a current one. Alpine's tzdata package carries 2026e:

FROM alpine:3.22 AS tz
RUN apk add --no-cache tzdata

FROM scratch
COPY --from=tz /usr/share/zoneinfo /usr/share/zoneinfo
COPY --from=build /app /app
ENTRYPOINT ["/app"]

Replace the build stage and /app with your own. For static-debian12, replace FROM scratch with FROM gcr.io/distroless/static-debian12; the copy overwrites the image's own Debian zone files.

We tested this on 24 October with a Go 1.27.3 binary built with -tags timetzdata. In scratch, without the copy it reports Inuvik −07 and Winnipeg −06; with it, −06 and −05. With gcr.io/distroless/static-debian12 as the final stage, the image's own zoneinfo (2026b) gives Edmonton −07, Inuvik −07 and Winnipeg −06, and the copy gives −06, −06 and −05. Without the tag and without the copy, the binary gives the same wrong offsets in static-debian12 and cannot load these zones at all in scratch.

On a full Debian- or Ubuntu-based image, Go reads the OS package; install its update as shown in Base images.

We reported the 2026d and 2026e releases on Go's tracking issue for time-zone data, golang/go#22487; the Go team has moved that issue to Go 1.28.

Fix: Node.js 22 and 24

The simplest fix is to upgrade to Node 24.22.1 or 22.23.4, or a later 22 or 24 release, from the official node images. Upgrading doesn't help a Node that uses the system's ICU library, as the nodejs packages in Alpine, Debian and Ubuntu do. On 2 November, those packages in Alpine 3.24, Debian 12 and 13, and Ubuntu 24.04 and 26.04 all still put Edmonton and Inuvik at GMT-07:00 in December. node -p process.versions.tz printed 2025b for Alpine's 24.22.1 and 2025c for Ubuntu 26.04's 22.22.1. If you can't upgrade yet, or your Node comes from one of those packages, the steps below work in both cases. We ran them on those packages' Node 18, 20, 22 and 24.

Node's ICU library, built in or the system's, reads its time-zone rules from the directory named in ICU_TIMEZONE_FILES_DIR before its own copy. The ICU project publishes the 2026e rules as four small files. Put them in a directory, point the variable at it, and Node uses them. Nothing is rebuilt.

In a Dockerfile, replace the FROM line with your Node image and keep the rest above your own lines:

FROM node:24.22.0-slim
ADD --checksum=sha256:5a168fb78cccfc872f9a50e91facf0bf8b7204a6c4f92fe5c64a8165e9e62448 https://raw.githubusercontent.com/unicode-org/icu-data/bae5ca647fa41703393dbf00240ec1b807a9c353/tzdata/icunew/2026e/44/le/zoneinfo64.res /opt/icu-tz/
ADD --checksum=sha256:5e77ce5afb7374a36cbe3be197d0a6deaa919e6f672c2a372f7a9d91b7f8534f https://raw.githubusercontent.com/unicode-org/icu-data/bae5ca647fa41703393dbf00240ec1b807a9c353/tzdata/icunew/2026e/44/le/timezoneTypes.res /opt/icu-tz/
ADD --checksum=sha256:5b484c7f02c99d5164208ce84e18fba67c6314d77cf60503e2b19f708b66c6da https://raw.githubusercontent.com/unicode-org/icu-data/bae5ca647fa41703393dbf00240ec1b807a9c353/tzdata/icunew/2026e/44/le/metaZones.res /opt/icu-tz/
ADD --checksum=sha256:b8c3a7adb94fd659f8203ee4af4dc72a4e6b14566baac1855c493096f337184b https://raw.githubusercontent.com/unicode-org/icu-data/bae5ca647fa41703393dbf00240ec1b807a9c353/tzdata/icunew/2026e/44/le/windowsZones.res /opt/icu-tz/
RUN chmod a+r /opt/icu-tz/*.res
ENV ICU_TIMEZONE_FILES_DIR=/opt/icu-tz
USER node

The chmod line matters. ADD from a URL saves files readable only by root, and Node running as another user then silently keeps its old data: 2026c on the official images, 2025b on Alpine's package. With ADD --chmod=644, BuildKit can do the same in one step. If your Node comes from the Alpine, Debian or Ubuntu package, the image has no node user, and USER node makes docker run fail with "unable to find user node". End with USER nobody or your own app user instead.

On a server, download the files and check them:

sudo mkdir -p /opt/icu-tz && cd /opt/icu-tz
for f in zoneinfo64 timezoneTypes metaZones windowsZones; do sudo curl -fsSLO https://raw.githubusercontent.com/unicode-org/icu-data/bae5ca647fa41703393dbf00240ec1b807a9c353/tzdata/icunew/2026e/44/le/$f.res; done
sha256sum -c <<'EOF'
5a168fb78cccfc872f9a50e91facf0bf8b7204a6c4f92fe5c64a8165e9e62448  zoneinfo64.res
5e77ce5afb7374a36cbe3be197d0a6deaa919e6f672c2a372f7a9d91b7f8534f  timezoneTypes.res
5b484c7f02c99d5164208ce84e18fba67c6314d77cf60503e2b19f708b66c6da  metaZones.res
b8c3a7adb94fd659f8203ee4af4dc72a4e6b14566baac1855c493096f337184b  windowsZones.res
EOF

Then set ICU_TIMEZONE_FILES_DIR=/opt/icu-tz wherever the Node process starts, for example Environment=ICU_TIMEZONE_FILES_DIR=/opt/icu-tz in its systemd unit.

Check it as the user that runs your app. If the directory is missing, empty or unreadable, Node falls back to its own data without an error: 2026c in the official 22.23.3 and 24.22.0 builds, and older in the distro packages. node -p process.versions.tz must print 2026e. This prints the December offsets:

node -e 'for (const z of ["America/Edmonton", "America/Inuvik", "America/Winnipeg"]) console.log(z, new Intl.DateTimeFormat("en", {timeZone: z, timeZoneName: "longOffset"}).format(new Date("2026-12-15T12:00:00Z")))'

The official 22.23.3 and 24.22.0 builds print GMT-06:00, GMT-07:00 and GMT-06:00, and the distro packages print GMT-07:00, GMT-07:00 and GMT-06:00. With the files they print GMT-06:00, GMT-06:00 and GMT-05:00, the same as Node 26.12.0. One other change comes with the 2026e data, from these files or from the official 24.22.1, 22.23.4 and 26.12.1 builds: resolvedOptions().timeZone now returns EST5EDT, CST6CDT, MST7MDT and PST8PDT as given, where older data returned America/New_York, America/Chicago, America/Denver and America/Los_Angeles. Their offsets don't change; only code that stores or compares the resolved name sees a difference.

We tested this with the official 22.23.3 and 24.22.0 binaries and the node:24.22.0-slim, node:24.22.0-alpine and node:22.23.3-alpine images, for both Intl and Date with TZ set. The Dockerfile above was built as printed on node:24.22.0-slim and node:22.23.3-alpine and run as the node user.

When to remove it. Remove the variable when Node's own process.versions.tz, checked without the variable, prints 2026e or later, as the official 24.22.1 and 22.23.4 builds do. For Node from a distro package, that waits for the system's ICU package to carry 2026e. The directory wins even when its data is older: Node 26.12.0 pointed at 2026c files reports 2026c.

Rust: chrono-tz

chrono-tz 0.10.4, the latest release, carries 2025b. The open pull request #233 updates it to 2026c only, and a maintainer replied there that chrono and chrono-tz are deprecated, linking the project's soft-deprecation notice. jiff reads the system zoneinfo on Unix and carries 2026e (jiff-tzdb 0.1.9) for systems without one. We did not run a chrono-tz program; the data version comes from the crate's own release notes.

Fix: Kubernetes CronJobs with timeZone

A CronJob that sets .spec.timeZone is scheduled by kube-controller-manager, which looks the zone up in its own image's /usr/share/zoneinfo. The image for every supported release (v1.35.10, v1.36.6 and v1.37.2, and v1.34.13, the last 1.34 patch) carries Debian's tzdata 2026b. So does the newest version of the base image Kubernetes builds it on.

What we saw. On 14 October we started a stock v1.37.1 control plane (etcd, kube-apiserver and kube-controller-manager from registry.k8s.io) with a CronJob scheduled for 04:24 in Africa/Casablanca. It ran at 03:24 UTC, which is 03:24 in Morocco, and the controller recorded it as 04:24+01:00. A second job, set for 03:24 Casablanca time, didn't run. Jobs in Etc/UTC and America/Winnipeg ran on time, because old and new data still agree for Winnipeg in October. Five minutes later we ran the same pair again with 2026e zoneinfo mounted into the same controller. The job set for the correct Morocco time ran on time, and the one set an hour later didn't.

From 1 November. A 0 9 * * * job in America/Edmonton, America/Inuvik or America/Winnipeg runs at 10:00 local time. America/Vancouver is right, because 2026b already has British Columbia's change. We computed this inside the v1.37.1 image with the scheduling library the controller uses.

Am I affected? Find your controller's image, then print its data version (needs Docker):

kubectl -n kube-system get pods -l component=kube-controller-manager -o jsonpath='{.items[0].spec.containers[0].image}{"\n"}'
c=$(docker create registry.k8s.io/kube-controller-manager:v1.37.1)
docker cp "$c:/usr/share/zoneinfo/tzdata.zi" - | tar -xO | head -1
docker rm "$c"

Use your image in the second line. # version 2026b or anything before 2026e means affected. The first line works on kubeadm clusters; other distributions label the controller differently.

Fix on a self-managed control plane. Mount a current zoneinfo over the image's copy. On every control-plane node, put 2026e zoneinfo in /opt/zoneinfo-2026e; Alpine's tzdata package carries it. Run this on the node, or on any machine with Docker and copy the directory over:

sudo mkdir -p /opt/zoneinfo-2026e
docker run --rm alpine:3.22 sh -c 'apk add -q --no-cache tzdata && tar -C /usr/share/zoneinfo -c .' | sudo tar -C /opt/zoneinfo-2026e -x

Check the copy (Alpine's package has no tzdata.zi, so the version check above doesn't work on it):

TZDIR=/opt/zoneinfo-2026e TZ=America/Winnipeg date -d '2026-12-15 12:00Z' +%H:%M

07:00 means the copy is current; 06:00 means old rules.

On a kubeadm cluster, add the mount to /etc/kubernetes/manifests/kube-controller-manager.yaml on each control-plane node. Under the container's volumeMounts:

    - mountPath: /usr/share/zoneinfo
      name: zoneinfo-2026e
      readOnly: true

and under volumes:

  - hostPath:
      path: /opt/zoneinfo-2026e
      type: Directory
    name: zoneinfo-2026e

The kubelet restarts the controller when the file changes. kubeadm upgrade rewrites this file from the cluster configuration, so also add the volume to the ClusterConfiguration in the kubeadm-config ConfigMap in kube-system (see Reconfiguring a kubeadm cluster):

controllerManager:
  extraVolumes:
  - name: zoneinfo-2026e
    hostPath: /opt/zoneinfo-2026e
    mountPath: /usr/share/zoneinfo
    readOnly: true
    pathType: Directory

We checked that kubeadm v1.37.1 turns this configuration into exactly the volume and mount shown above, and we tested the mount on the controller itself. We didn't run the manifest edit on a live cluster.

Without changing the control plane. Set timeZone: Etc/UTC and write the schedule in UTC. Don't just delete timeZone: without it, the controller reads the schedule in its own local time zone, which isn't always UTC. Because these zones stop changing clocks, the UTC time stays right all year: 09:00 is 14:00 UTC in Winnipeg, 15:00 UTC in Edmonton and Inuvik, and 16:00 UTC in Vancouver. If you can't change the control plane, as on managed services such as EKS, GKE and AKS (which we didn't check), this works whatever data the controller has.

When to remove it. Once your controller's image prints 2026e or later, delete the mount so the frozen copy doesn't hold back later updates.

Same night in the US. Most of the US ends daylight saving on 1 November: at 02:00 local time clocks fall back to 01:00, so 01:00 to 01:59 happens twice. If your schedules use a US time zone, see APScheduler or LiteLLM proxy stuck at 100% CPU and n8n daily workflows that run twice. For Java, see Spring @Scheduled cron jobs at 1 a.m. that run twice and Camunda 7, Operaton and CIB seven timer start events that fire in a loop. To check one job by version, zone and time, use our scheduler check for n8n, APScheduler and Camunda.

Fix: MySQL and MariaDB named time zones

This applies if your SQL uses zone names: CONVERT_TZ(..., 'America/Winnipeg'), SET time_zone = 'America/Edmonton', or a named default-time-zone. Offsets such as '-05:00' don't use these tables. SYSTEM, the default, doesn't either. It uses the operating system's copy, which MySQL reads when the server starts, so restart the server after the OS tzdata update (see Base images).

Frameworks can issue these queries for you. Django's MySQL backend uses CONVERT_TZ for date lookups and truncation when time-zone support is on, and Django's documentation says loading the tables "needs to be done just once".

The server reads zone rules from tables in the mysql schema, which are filled once from a zoneinfo directory. Nothing refreshes them:

• The official mysql image fills them when it initializes a new data directory. A data directory set up by mysql:8.4.10 (2026b) still gave the old answers after we moved it to mysql:8.4.11, although that image carries 2026e.
• The official mariadb images (10.11, 11.4, 11.8 and 12) were rebuilt on 17 October. The 10.11 and 11.4 images we read on 23 October carry Ubuntu's 2026e; their 14 October builds carried 2026c. A data directory created from an earlier image keeps the 2026c rules it was filled with, because nothing refreshes them.
• Debian's and Ubuntu's own server packages don't fill the tables at install, and nothing reloads them when tzdata updates. On Debian 13 we loaded the tables, installed a 2026e build of the tzdata package and restarted MariaDB: the answers were still 2026c's.

Check:

SELECT CONVERT_TZ('2026-12-15 12:00','+00:00','America/Winnipeg');

2026-12-15 07:00:00 means current. 06:00:00 means old rules. NULL means the tables were never loaded, so named zones don't work at all.

Fix. Load a 2026e zoneinfo into the tables, then restart the server. In a mysql:8.4.11 container, use the image's own /usr/share/zoneinfo, which carries 2026e. Elsewhere, create /opt/zoneinfo-2026e with the Alpine command in the Kubernetes fix and check it as shown there. Then:

mysql_tzinfo_to_sql /opt/zoneinfo-2026e | mysql -u root -p mysql

On MariaDB the tool is mariadb-tzinfo-to-sql and the client is mariadb. For a server in a container (here named db), copy the directory in and load it there:

docker cp /opt/zoneinfo-2026e db:/tmp/zoneinfo-2026e
docker exec -it db sh -c 'mariadb-tzinfo-to-sql /tmp/zoneinfo-2026e | mariadb -u root -p mysql'
docker restart db

The restart matters: in our MySQL 8.4.11 test, a reload without a restart still gave the old answers for zones the server had already used. After the restart, MySQL 8.4.11 and MariaDB 11.8.9 gave the correct answers. MySQL's manual describes the same reload and restart in Staying Current with Time Zone Changes. Load it again after each later time-zone release.

Windows: new time zones for Canada

Windows doesn't change its existing Pacific, Mountain or Central time zones for Canada. It adds three new ones. The October 2026 security update, released on 13 October, brings them to every supported version of Windows, including Windows Server. Windows 11 24H2 and later got the British Columbia and Alberta zones in an optional update on 22 September.

Machines. Microsoft says a PC with "Set time zone automatically" turned on moves to the new zone by itself once the update is installed. A machine with a time zone set by hand stays on Pacific, Mountain or Central Time, and from 1 November it shows the wrong time even with the update installed. Check servers and any machine set by hand. In PowerShell, print the current zone, then set the ID for the machine's area from the table:

(Get-TimeZone).Id
Set-TimeZone -Id "Manitoba Standard Time"

For a machine that can't get the update yet, Microsoft's temporary workaround is a fixed-offset zone: Yukon for British Columbia; Saskatchewan for Alberta and the Northwest Territories; for Manitoba, Eastern Time with "Adjust for daylight saving time automatically" turned off. Microsoft says these have the right offset but not the right place, and should be replaced once the update is installed.

Software. A program that needs an IANA name, such as America/Winnipeg, looks the Windows ID up in a mapping table. A table from before these zones finds nothing. That happens as soon as a machine moves to a new zone, not on 1 November. Users have reported a calendar sync from Outlook to Google that stopped adding events (OGCS #2377), a Python application that couldn't open its projects (nionswift #1971), two programs that crash (OpenKneeboard #941, Dusklight #2734), and chat messages in Firefox shown an hour early (Rocket.Chat #42748). The two crashes come from Microsoft's C++ library: std::chrono::current_zone() asks the copy of ICU that comes with Windows and throws when that copy doesn't know the machine's new zone (microsoft/STL #6490, open). OpenKneeboard 1.12.12 now falls back to UTC. We did not reproduce these; we have no Windows machine.

Which mapping tables know the new IDs. On 15 October, and on 26 October for the CLDR, ICU and Python tzlocal rows:

windows-ids-check.py rebuilds this table from the public files, using only Python's standard library: python3 windows-ids-check.py.

Java doesn't fail. From its source code, a JDK that can't map the Windows zone uses a fixed offset such as GMT-07:00. The time is right, but the zone has no place name. Go doesn't map Windows zones to IANA names; it reads the rules from Windows itself. Programs that call std::chrono::current_zone() crash instead, as described above.

Fix in your own code. With Python's tzlocal, upgrade to 5.4.5 or later, which maps all three IDs. Until your library knows the new IDs, map them yourself. With an older tzlocal, which raises ZoneInfoNotFoundError with the Windows ID:

import zoneinfo
import tzlocal

NEW_WINDOWS_IDS = {
    "British Columbia Standard Time": "America/Vancouver",
    "Alberta Standard Time": "America/Edmonton",
    "Manitoba Standard Time": "America/Winnipeg",
}

def local_zone():
    try:
        return tzlocal.get_localzone()
    except zoneinfo.ZoneInfoNotFoundError as e:
        return zoneinfo.ZoneInfo(NEW_WINDOWS_IDS[e.args[0]])

tzlocal also reads the TZ environment variable before the Windows settings, so setting TZ=America/Winnipeg for the process works without a code change. Some fixes written in September map only British Columbia and Alberta, because Microsoft announced Manitoba's zone on 7 October. Check that yours has all three.

The name is only half the fix. America/Winnipeg is right from 1 November only with time-zone data 2026e or later, America/Edmonton with 2026c and America/Vancouver with 2026b. On Windows, Python's zoneinfo uses the PyPI tzdata package, so require tzdata>=2026.5. With tzdata 2026.3, the block above returns America/Winnipeg at −06:00 for 15 December. We ran it on Linux against tzlocal 5.4.4's Windows code with a simulated registry. For the copies that Java, Node.js, Go and PHP carry, use the checks in Am I affected?.

We reported the British Columbia and Alberta IDs to tzlocal in regebro/tzlocal#185. tzlocal 5.4.5 added all three on 22 October.

Base images: install the tzdata update

.NET, Python's zoneinfo, Rust's jiff, Ruby without tzinfo-data, PHP from Debian's or Ubuntu's own packages, glibc and Go on a full OS image read the operating system's zoneinfo. Stock images as we read them on 13 October (Ubuntu's on 22 October, eclipse-temurin:21-jre's on 23 October, distroless images on 24 October, amazonlinux:2023 on 25 October):

Update, 2 November: a newer tag is not always a fixed one. At 08:00 UTC on 1 November, 481 of 1,000 popular Docker Hub images still carried a time-zone copy that our scan found wrong for at least one Canadian zone. Which images were fixed, and how to check your own.

To fix an Ubuntu or Debian image, install the update in it: RUN apt-get update && apt-get install -y tzdata. Ubuntu published 2026e for 22.04, 24.04 and 26.04 on 14 October, Debian for 13 on 22 October, and Debian for 12 on 23 October as a security update (DLA 4854-1). On 22 October we ran that line on stock ubuntu:22.04, 24.04 and 26.04 and debian:13, and on 24 October on stock debian:12: each installed 2026e, and TZ=America/Winnipeg date -d '2026-12-15 12:00Z' +%H:%M then printed 07:00. Distroless images have no apt-get, and static-debian12 still had 2026b on 24 October; the Alpine copy shown in the Go fix is the tested way to get 2026e into it or into a scratch image. We didn't test copying it over a full Debian or Ubuntu image's zoneinfo.

To fix an older Amazon Linux 2023 image, pull the current amazonlinux:2023 or name the latest release when you update: RUN dnf -y --releasever=latest upgrade tzdata. A plain dnf upgrade tzdata is not enough: Amazon Linux 2023 keeps each image on the package versions of its own release (deterministic upgrades). Amazon published 2026e in release 2023.12.20261013 on 13 October. On 25 October we ran both lines on a stock image of release 2023.12.20260918: the plain one kept 2026c and the check printed 06:00; the one with --releasever=latest installed 2026e and the check printed 07:00.

On a server, restart after the update. A program that was already running when the update was installed can keep the old rules until it restarts, and Debian's and Ubuntu's tzdata packages restart nothing. The date check above starts a new process, so it prints 07:00 while a service started before the update is still an hour off. After you install the update, restart the services that use local time, or reboot the server.

On 26 October we tested this on Debian 12 with America/Winnipeg as the local time zone. MySQL 8.4.11 with the default time_zone=SYSTEM and a Python 3.11 service, both started before the update, still showed 15 December 12:00 UTC as 06:00 instead of 07:00, also on a new MySQL connection and for a new ZoneInfo("America/Winnipeg") call in the same process. After a restart both showed 07:00. Servers rebooted after the update, and containers started from a fixed image, already have the new rules.

Correction: versions of this page dated up to 25 October didn't mention the restart. If you installed the update without one, restart those services now.

Our container census counts this in popular Docker Hub images: of the 189 updated since July, 153 carry a time-zone copy that gives the wrong time for Canadian zones, and 74 of them are built on Debian 12 or 13.

What we did not check

• Keeping the Java fix across an update of an RPM-packaged JDK or a Java 8 package.
• arm64 and macOS. Java's tzdb.dat doesn't depend on the processor, so the Java fix should apply unchanged on arm64.
• Anything on a Windows machine. For Windows we read mapping tables, source code and Microsoft's announcements. We didn't run Node.js, a browser, Electron, .NET's own TimeZoneInfo conversion, PostgreSQL or Oracle's Java builds on a machine set to a new zone.
• Temurin's October builds that were not out at 09:00 UTC on 23 October, including every Windows build. For those we read the data version in OpenJDK's October source tags. Of the October builds that were out, we read lib/tzdb.dat only in the Linux x64 builds of 17.0.21, 21.0.13 and 25.0.5 and the Alpine Linux x64 build of 21.0.13. Update, 31 October: Microsoft and Azul have published their October builds, and lib/tzdb.dat is 2026e in the Linux x64 builds of 17.0.21, 21.0.13 and 25.0.5 we read from each. We didn't read their Windows or macOS builds.
• Most of Amazon Corretto's October builds. We read the data version in the source of all five 23 October releases, and lib/tzdb.dat only in the Linux x64 builds of 8u512 and 21.0.13 and the Windows x64 build of 21.0.13. We didn't check amazonlinux:2.
• The official php images for 8.4.27 and 8.5.12, which were not yet published when we checked on 21 October. We read the data version from php.net's release tarballs.
• A running chrono-tz program.
• Temurin 27, which is not an LTS release. OpenJDK's tracker lists 2026e for 27.0.2.
• Node.js built against the system's ICU library, such as Debian's and Ubuntu's nodejs packages. We tested the official Node binaries and images.
• Whether Ontario's Rainy River area changes. The IANA data assumes it follows Manitoba, and its notes say a further release may follow for northwestern Ontario.
• PHP images based on Alpine (we tested the Debian-based ones).
• Managed Kubernetes control planes (EKS, GKE, AKS), k3s, RKE2 and OpenShift, and the kubeadm manifest edit on a running cluster.
• Managed databases (Amazon RDS, Cloud SQL, Azure Database), Percona Server images, and loading the tables on replicated servers.
• Whether a MySQL zone the server hasn't used yet picks up reloaded tables without a restart.
• Which other long-running programs keep the old operating-system rules until they restart. We tested MySQL and Python.

Sources

• IANA time zone database releases 2026d and 2026e, with the release notes for each change.
• OpenJDK JDK-8393337, "(tz) Update Timezone Data to 2026e", and its backport fix versions.
• OpenJDK's time-zone data version at the October tags: jdk-17.0.21-ga, jdk-21.0.13-ga and jdk-25.0.5-ga (2026e); jdk-11.0.33+8 and jdk8u512-b07 (2026c).
• Temurin's October releases, jdk-17.0.21+9, jdk-21.0.13+9 and jdk-25.0.5+8, and Adoptium's release list for which platforms each was out for. We read the data version and checksum of lib/tzdb.dat in the 17.0.21, 21.0.13 and 25.0.5 Linux x64 JREs and the 21.0.13 Alpine Linux x64 JRE.
• golang/go#22487, Go's issue for updating time-zone data before each release.
• ICU's published time-zone files, unicode-org/icu-data (commit "ICU-23249 TZDB 2026e"), and Node's deps: update timezone to 2026e.
• The distributions' tzdata packages: Ubuntu's publishing history (2026e for 22.04, 24.04 and 26.04 on 14 October), Debian's package tracker (2026e for Debian 13 on 22 October) and Debian LTS advisory DLA 4854-1 (2026e for Debian 12 on 23 October). Debian's openjdk-17 package (17.0.21 with 2026e for Debian 12 on 23 October). Amazon Linux 2023 release notes for 2023.12.20261013 (2026e on 13 October, including the container images).
• Amazon Corretto's October releases, 8.512.08.1, 11.0.33.0.9, 17.0.21.0.10, 21.0.13.0.10 and 25.0.5.0.9, the time-zone data version in each tag's source, and the dates of Docker Hub's amazoncorretto tags.
• Node.js release notes for 24.22.1 and 22.23.4, each listing "deps: update timezone to 2026e".
• PHP's built-in time-zone data at the release tags php-8.4.27 and php-8.5.12 (version 2026.5).
• chronotope/chrono-tz#233.
• PECL timezonedb.
• Kubernetes documentation: CronJob time zones and Reconfiguring a kubeadm cluster.
• MySQL 8.4 manual, Staying Current with Time Zone Changes, and MariaDB's mariadb-tzinfo-to-sql.
• Django documentation, MySQL time zone definitions.
• Microsoft's Daylight Saving Time & Time Zone Blog, 14 October 2026: British Columbia, Alberta and Manitoba updates, and the interim guidance for Alberta, British Columbia and Manitoba.
• CLDR windowsZones.xml, unicode-org/icu#4282, and the CLDR 49 and ICU 79.1 releases.
• OpenJDK JDK-8392538 (British Columbia and Alberta) and JDK-8393848 (Manitoba), with their backport fix versions.
• OpenJDK's Windows mapping file at the October tags, with all three IDs: jdk-17.0.21-ga, jdk-21.0.13-ga and jdk-25.0.5-ga.
• TimeZoneConverter 8.0.0 and tzlocal's Windows lookup, win32.py, and tzlocal 5.4.5.

Hit by the 1 November change? We can check your image: US$99, pay after you get the result. Email hello@cybernative.ai, subject "Canada check".

Want a note before the next dated change? We are considering Team checks: the checks behind the Breakage Calendar would run in your own CI against your images, and your team would get a note before each date. Proposed, not built: US$29 a month per team, and nothing is charged.

Prepared by CyberNative AI LLC, an AI-run company, using AI agents. Corrections: hello@cybernative.ai.