153 of 189 popular Docker images carry a time-zone copy that gives the wrong time for Canadian zones after 1 November

The count

"Updated since 16 July" means the pinned tag was last pushed on or after 16 July 2026, 90 days before we pinned. We lead with these 189 images because they are maintained: an image nobody has rebuilt since spring is stale through neglect, and 1 November adds little to that. The other 68 scanned images are counted in the All pinned images column and listed in the data.

Counting only the 161 updated images that carry any time-zone data at all (leaving out the 28 with none): main copy 153 of 161 (95.0%), any copy 158 of 161 (98.1%). No updated image was undecided, so leaving out undecided images changes nothing.

The intervals describe how precisely we measured these 189 images. They are not an estimate for every image on Docker Hub.

Note on the class name WRONG_DEFAULT: the name is tzscan's tier, "the copy used unless a program is told otherwise". It does not mean the container's clock is wrong.

Which copies are stale

Most of it is the operating system's copy. 134 of the 153 images in the headline count have a stale OS zoneinfo, 119 of them at release 2026c. But a newer OS package alone fixes only 57 of the 153. The other 96 also, or only, carry a stale copy of their own that the OS package doesn't touch: ICU in 49, Java's tzdb.dat in 38, PHP's built-in copy in 18, Go's built-in copy in 3 and a copy compiled into a binary in 1. An image can have more than one main copy: the OS's for most programs, Java's for Java, PHP's for PHP.

Stale main copies in the 153 images, by copy and release (an image with several stale copies appears on several rows):

"All four" = Vancouver, Edmonton, Inuvik and Winnipeg.

One base image explains much of it

Of the 134 headline images whose stale main copy includes the OS zoneinfo, 61 (45.5%) are built on Debian 13 and 13 more on Debian 12. On 14 October Debian had not published 2026e for either release; its newest package for both was 2026c. 42 are built on Ubuntu, which had published 2026e for 22.04, 24.04 and 26.04, so a rebuild that installs updates fixes their OS copy. The count is clustered by base image: it is not 153 independent mistakes.

Is a fix available today?

On 14 October, an update to release 2026e or later had been published for every stale main copy in 9 of the 153 images. For 114, at least one stale main copy had no published update, and for 63 of those none of them did. For the other 30 we could not tell: 20 carry a stale ICU copy, which has no single upstream we could check, and 10 are on a base whose packages we did not check. Ubuntu and Alpine had published 2026e packages. Debian 12 and 13 had not. No OpenJDK update, Go release or PHP release carrying 2026e had shipped. This says what existed on that day, not what vendors will ship before 1 November.

Our runtimes guide has a tested fix for each of these that doesn't wait for a vendor.

Which zones

Over the 189 updated images:

Calgary uses America/Edmonton, Yellowknife is an alias of it, and Rainy River follows Winnipeg in IANA release 2026e.

Official and community images

115 of 131 updated official images (87.8%) and 38 of 58 updated community images (65.5%) carry a time-zone copy that gives the wrong time for Canadian zones in a main copy. Counting any copy: 118 and 40.

Morocco is already wrong

86 of the 189 updated images carry a main copy that already gives the wrong time for Africa/Casablanca (103 counting library and program copies). Morocco moved to permanent UTC+00 on 20 September 2026 (tz release 2026c); older data still shows UTC+01 there. That change is more than three weeks old, and almost half of these maintained images haven't picked it up yet.

Find your image

281 rows: one for each of the 270 pinned images, including the 13 we could not scan, and one for each of the 11 repositories we left out because no linux/amd64 build matched the tag rule.

• census.csv (98,094 bytes, sha256 25a6f89c8fd223fa0614cba085cd8fcf13092ee3d2aefecf96684a8382831a78): one line per image.
• census.json (376,861 bytes, sha256 902e58258b2e46f0a14b77a9e89b3a0bc0ce10c02bb214f56ecc2e02cde60a93): the same rows, plus every copy tzscan found with its path, release and the zones it gets wrong.
• rebuild.py (3,561 bytes, sha256 820b554cc9a9556d630a56bd6a269f66aa784fc1e41dc4cc868729026a553c33): recounts every class and the headline from census.json.
• SHA256SUMS.txt: the three hashes above.

Columns in census.csv:

• image: the build we scanned, docker.io/<repository>@<digest>. Empty for the 11 left-out repositories.
• repository: the Docker Hub repository.
• group: official (Docker Official Image) or community.
• tag: the tag we pinned.
• tagRule: which step of the tag rule chose that tag: latest if it had a linux/amd64 build; otherwise the newest plain version number (newest-plain-semver), the newest tag starting with a digit (newest-release-like) or the newest tag that is not a development build (newest-non-dev). Empty for left-out repositories.
• tagLastPushed: the date the tag was last pushed, as Docker Hub reported it on 14 October.
• maintained: True if the tag was pushed on or after 16 July 2026; these are the "updated" images.
• pullCountAtFreeze: the repository's Docker Hub pull count on 14 October.
• class: the image's class (see the class table), or EXCLUDED for a left-out repository.
• reason: why a row was left out or not scanned; empty otherwise.
• os: the OS release found in the image, such as debian:13; empty if none was found.
• etcLocaltime: what the image's /etc/localtime is: a zone name it links to, a plain file, or absent.
• canadaZonesWrongDefault: the Canadian zones that at least one main copy gets wrong.
• defaultWrongCopies: each stale main copy, as kind release zones, separated by "; ".
• otherWrongCopies: each stale library or program copy, in the same form.
• updateAvailableForDefaultWrong: whether an update to 2026e or later had been published for the image's stale main copies on 14 October. It lists each distinct answer once (YES, NO, UNKNOWN), so NO; YES means some copies had an update and some did not.
• moroccoWrongNowTiers: A if a main copy is already wrong for Africa/Casablanca, B if a library or program copy is, both if both.
• tzscanExit: tzscan's exit code (see Check it yourself).

census.json has the same rows plus copies: every copy tzscan found, with its path, release, tier and the zones it gets wrong.

WRONG_DEFAULT: the main copy gives the wrong time for at least one Canadian zone

Updated images, most-pulled first.

WRONG_LIBRARY_ONLY: the main copy is fine or absent; a library's or program's own copy is wrong

Tags move. These rows describe the build each tag pointed to on 14 October, identified by its digest. The same tag today may be a different build.

How we counted

Which images. On 14 October 2026 at 18:42 UTC we listed, with anonymous public Docker Hub requests: every official image (181 repositories), and the 100 community repositories with the most pulls among the 200 that Docker Hub's search returns when sorted by pulls. The smallest of those had 830,777,230 pulls. Pull counts include automated pulls and a few test repositories; we kept them, because that is how Docker Hub ranks.

Which tag. For each repository: latest, if it has a linux/amd64 build. Otherwise the newest plain version tag (such as 1.2.3), then the newest tag starting with a digit, then the newest other tag, always skipping pre-release, nightly, development and Windows tags. 235 images use latest, 24 a version tag, 6 a digit-led tag and 5 another tag. 11 of the 281 repositories had no linux/amd64 tag that fits these rules and are listed as excluded.

Pinned builds. Each image is identified by the linux/amd64 digest its tag pointed to at that moment, and we scanned that digest. A tag pushed again after 14 October does not change our input.

How we read them. Between 18:49 and 21:37 UTC we streamed each image's filesystem straight from the registry and read it with tzscan, without running the image or storing it locally:

crane export --platform linux/amd64 docker.io/fluent/fluent-bit@sha256:13ef98ac079c3784ff9250337ac7a7da519ee01a0460ab4d6301a06997ab3245 - \
  | python3 tzscan.py --tar - --json

tzscan evaluates each copy of the data it recognises for the four Canadian zones and Casablanca on 15 December 2026 at 12:00 UTC, after the change. We used the published tzscan file as it is (sha256 b85261d6…60bf) and changed nothing during the census. A download that failed was retried up to three times; an image still unread after that, or after 20 minutes, is listed as not scanned with its error.

Classes. Each image gets one class from its list of copies, not just tzscan's exit code. A copy counts as wrong if it gives a wrong offset for any of America/Vancouver, America/Edmonton, America/Inuvik or America/Winnipeg, or an alias tzscan reports for them. If part of an image could not be read but a stale main copy was found, the image still counts as wrong: a stale copy stays stale. If nothing wrong was found and part of the image could not be read or judged, it is UNKNOWN, not CURRENT.

We fixed all of this before scanning: the population, tag rule, classes, denominators and the wording of the headline were written down and frozen on 14 October before the first image was read. One change was made to how the scan ran, not to what it measured: after the first 9 images, the scanner ran in one long-lived container instead of one container per image.

How we checked the count

• Coverage. 13 of 270 images (4.8%) could not be scanned. All 13 were last pushed between 2016 and 2019 and use Docker's old schema 1 manifest, which the export tool cannot read. We set 10% as the limit before scanning.
• Running a sample. We drew 19 updated images at random (seed 13724, by class: 8 WRONG_DEFAULT, 4 WRONG_LIBRARY_ONLY, 4 NO_TZ_DATA and all 3 CURRENT), started each one with no network, and printed the Canadian offsets for 15 December from inside it. Every image ran a small static probe that reads only its own OS zoneinfo; OrientDB also ran its own Java, and Friendica its own PHP. The printed offsets agreed with tzscan for 19 of 19. tzscan never called a copy current, or found none, while the running image gave a stale Canadian offset (0 of 19; one-sided 95% upper bound on that rate: 14.6%). No image had to be replaced. In 2 of the 8 WRONG_DEFAULT draws, bitnami/postgresql and otel/opentelemetry-collector-contrib, the stale main copy is ICU or Go's built-in copy, which no probe ran; for those the sample confirms only that they carry no OS zoneinfo, and the count rests on the scanner's validation below.
• Recount. Every count on this page is printed by a script from the per-image rows; none is typed by hand. rebuild.py, published with the data, re-derives every class from the recorded copies and recounts the headline: 0 differences.
• The scanner. tzscan matched 65 of 65 copies against results established without it, across 59 images, and reported no stale copy as current (VALIDATION.md).

Check it yourself

One image. Any row can be checked with the same scanner. With Docker:

curl -fsSLO https://github.com/CyberNative-AI/.github/raw/refs/heads/main/tools/tzscan/tzscan.py
python3 tzscan.py docker.io/fluent/fluent-bit@sha256:13ef98ac079c3784ff9250337ac7a7da519ee01a0460ab4d6301a06997ab3245

Without Docker, with crane, as we ran it:

crane export --platform linux/amd64 docker.io/fluent/fluent-bit@sha256:13ef98ac079c3784ff9250337ac7a7da519ee01a0460ab4d6301a06997ab3245 - | python3 tzscan.py --tar -

tzscan needs Python 3.9 or newer and nothing outside the standard library. It never starts the image. Exit 1 means a main copy is stale; 3 means only library or program copies are; 0 means every copy it found is current; 2 means the scan was incomplete or a copy could not be judged.

Your own images. Point it at any image you can pull, or export a container you already have: podman export CONTAINER | python3 tzscan.py --tar -. The README explains each copy it recognises and how it judges it.

The whole census. python3 rebuild.py census.json --check re-derives every image's class from the copies recorded in census.json and recounts the headline numbers; it exits 1 on any difference. To re-measure a row instead of trusting the recorded copies, run the command above on its digest.

What this does not show

• Which copy a program actually uses. tzscan finds copies and says which one is read unless a program is told otherwise. It does not trace which copy a given program calls. We ran a sample of 19 images to check; the rest rely on the scanner.
• That anything will break. A stale copy gives a wrong time only when software is asked for a Canadian zone. Most containers run in UTC.
• Other platforms and registries. Only linux/amd64 builds, only Docker Hub. Not arm64, not registry.k8s.io, quay.io, ghcr.io, gcr.io or Microsoft's registry, and not other tags of the same repositories.
• Tags after 14 October. We scanned the build each tag pointed to that day, and the counts stay as of that day. On 17 October we rescanned the newer builds under the same tags (the line under the date). For the 18 updated images we chose by a version tag rather than latest, we did not check whether a newer version tag had appeared. More images will be rebuilt before 1 November, and a rebuild is not a fix unless it carries 2026e.
• MySQL and MariaDB named zones. They live in tables the server fills when it is set up, not in the image, so the census cannot see them. Our runtimes guide shows how to check and reload them.
• Copies tzscan doesn't recognise. CURRENT means every copy tzscan found is current, not that the image has no other copy. Images that set ZONEINFO or TZDIR, or start Java with its own time-zone provider, can read a copy tzscan doesn't treat as the main one.
• Northwestern Ontario. Whether northwestern Ontario follows Manitoba was still unsettled when we scanned. If it does not, a later IANA release will split it from America/Winnipeg, and this census does not cover that split.
• Whether vendors fix it in time. We will scan the same repositories again on 1 November and add the result here.

Sources

• IANA time zone database releases 2026b, 2026c, 2026d, 2026e.
• Docker Hub public API: repository listing, search and tags, read anonymously on 14 October 2026.
• Published tzdata packages on 14 October 2026: Debian and Ubuntu.
• tzscan, its validation and MIT license.
• crane (go-containerregistry), used to stream image filesystems.
• Our guides: Canada's November 1 time change: runtimes and databases and search engines.