Nov 1 Breakage Forecast: method

What we forecast

1. The count. Of the images in the frame below, how many will carry a time-zone copy that our scan judges to give the wrong UTC offset for at least one of America/Vancouver, America/Edmonton, America/Inuvik or America/Winnipeg at 2026-11-01 08:00 UTC, at the tag each repository points to then.
2. Fix calls. For a list of named repositories that are wrong at the freeze, the probability that the image will be judged right by 1 November.

"Wrong" means a copy of the time-zone data that the software in the image uses by default (the operating system's zoneinfo, a Java runtime's tzdb.dat, Node.js or ICU data, PHP's built-in database and similar) is judged to give the wrong offset, as described under "The scan": measured for zoneinfo-format copies, inferred from the tz release label for Java and ICU copies. It does not mean a container shows the wrong time: most containers run in UTC. We judge every copy against tz release 2026e, the first release with all four changes. If a later tz release comes out before 1 November we report it, but we do not score against it.

At 08:00 UTC on 1 November, every copy older than 2026e is already wrong for Winnipeg (its old rule fell back at 07:00 UTC). A copy wrong only for Vancouver is still right until 09:00 UTC. So the 08:00 UTC count is the same as "wrong for Edmonton, Inuvik or Winnipeg". We checked this on the compiled data of each tz release from 2025c to 2026e, not on each vendor's copy.

The frame

All 181 official Docker Hub images, plus the 819 community repositories with the most pulls among those our searches of Docker Hub find (each with at least 57.9 million pulls). Docker Hub's anonymous search caps each query at 200 results, so we ran every one- and two-character search and listed the namespaces we found; an independent check with 120 three-character searches found no repository above the cut that the frame had missed. This is not provably the 1,000 most-pulled images. Pull counts are lifetime totals, so the frame includes old, unmaintained repositories; the page shows "maintained" (main tag pushed on or after 16 July 2026) beside the whole frame.

Each repository is followed at one tag (its main tag, fixed on 18 October) and on linux/amd64 only. Repositories with no linux/amd64 image, or whose image could not be read, are counted as not scanned.

The scan

Each image is read without running it, by streaming its layers through tzscan (open source, same version for every scan). tzscan records the time-zone copies it recognises (operating-system zoneinfo files and archives, zoneinfo embedded in Go and other programs, PHP's built-in database, Java runtimes' tzdb.dat, ICU data and others) and which of them the software uses by default. A copy it does not recognise is not counted. How a copy is judged depends on its format:

• Measured: for zoneinfo-format copies (including Go's and PHP's), tzscan decodes the data and reads the UTC offset each of the four zones gives.
• Inferred from the label: for Java tzdb.dat and ICU copies, tzscan reads the tz release label inside the file (for example "TZDB header version 2026b") and judges the copy by what that release gives; it does not decode their offsets. In a spot check of two Java images, java.time's offsets agreed with what the label predicted.

An image is "right" when every recognised default copy is judged right this way. The census of 18 October pinned the main tag of 945 repositories (the other 55 have no linux/amd64 image) and scanned 923 of them; 22 old repositories could not be pulled by digest. The 77 not scanned are reported beside every count. Every day from 19 October we read each tag again and scan only images whose digest changed. An image counts as fixed only when a full scan of its new digest judges every recognised default copy right. A release note or OS package version is never enough: in this study several rebuilt images got a fixed operating-system copy while another default copy (a Java runtime, Node.js's ICU data, a distribution's ICU library) stayed wrong, so the image stayed wrong.

How the forecast is made

1. Routes. For every wrong copy in every wrong image we record its published fix route on the freeze day: a fixed package already in the image's OS archive (a rebuild is enough), a Debian base image build, a runtime release (Java, Node.js, PHP), a vendor-specific copy whose fix we cannot route, or no published fix (for example an operating system past its end of life, a Go or ICU copy with no 2026e release, PHP 8.3 and older). An image leaves the count only when every wrong default copy has an open route and the image is rebuilt after the last route opened: an image is as slow as its slowest copy.
2. Shared events. Events that many images depend on are drawn once per simulated run, so their children move together: Debian base image builds, the official Java (Eclipse Temurin) image update, distroless and other parent images, and the official-image rebuild cascade. Events already seen by the freeze enter as observed facts with their public times.
3. Rebuilds. For a community repository, the rebuild rate comes from the repository's recent push activity: the number of distinct days in the 90 days before 19 October on which any of its 100 most recently pushed tags was last pushed, divided by 90. Docker Hub keeps only each tag's latest push, and nightly or development tags count too, so this is a repository-wide rate, not the followed tag's own history. Checked against the 5.5 days before 19 October, it predicted 41.3 moves of the followed tags of 119 maintained community repositories and 29 moved, so the rate is scaled by 29/41.3. Official images re-push all their tags together, so they use one pooled rate (14 of 45 maintained official repositories moved in the same 5.5 days) plus the rebuild that follows a parent image build. Both rates carry a stated uncertainty in each run. The check of this rate registered on 19 October closed on 24 October at 14:15 UTC: 65 of those 119 repositories moved their followed tag in the five days, against 41.3 predicted by the unscaled rate (ratio 1.57, inside the 0.5 to 2 range set in advance), so the rates stand as described. The scaled rate expected about 29 moves, and 27 of the 45 maintained official repositories moved outside the 20 October Debian rebuild against about 13 expected, so both rates ran low that week. Run with both rates set to that week's observed values, the forecast is about 8 images lower and stays inside its interval; the frozen forecast keeps the rates above. A rebuild after the route opened fixes the image with a measured probability (100 of 109 such rebuilds outside linuxserver were fixed); a linuxserver image is fixed only if it is rebuilt after its own base image's first push with fixed data.
4. Other changes. Images can also leave the count in ways outside the route table (a base-image switch, a vendor patch), and right images can become wrong. Both rates are measured from the daily reads before the freeze and drawn in each run.
5. Uncertainty. 20,000 simulated runs, seed fixed. The forecast is the median count; the interval is the 5th to 95th percentile (90%). Unmeasured inputs (for example the chance a vendor ships a fixed copy) are drawn from stated ranges in each run.
6. Floor. The floor is the number of images wrong at the freeze whose slowest wrong copy had no published fix route on the freeze day. It is a fact about the freeze day, not a lower bound: an image can still leave the count through a change outside the route table.

Fix calls

Chosen from freeze-day data only, before any later scan: the 20 most-pulled maintained repositories wrong at the freeze; if not already included, the 3 most-pulled maintained wrong repositories with a Java route and the 3 whose only route is an OS rebuild; and the 5 remaining maintained wrong repositories with the highest forecast probability. Each call carries the model's probability p that the image is right by 1 November; the call is "fixed" if p is at least 0.5.

Scoring on 2 November

• Observed count: a full scan of every frame tag, read between 1 November 08:00 UTC and 2 November 12:00 UTC, judged with the same scanner and the same measured or label-inferred rules as above.
• Count: whether it falls inside the 90% interval, and the absolute error against the comparator.
• Comparator: the freeze-day count, meaning nothing changes after the freeze (the count stays where it was on the freeze day, and no call is fixed). If the freeze-day count is closer than the forecast, we say so.
• Fix calls: calls right of calls total, and the Brier score (mean of (p − o)², o = 1 if fixed in time), against the freeze-day comparison's Brier score (p = 0 for every call, which equals the share fixed).
• Fixed in time: at the digest the tag points to at the first read at or after 1 November 08:00 UTC, the scanner judges every recognised default copy right. An image fixed earlier but wrong again then is not fixed. A call we cannot score (tag deleted, no linux/amd64, scan fails twice) is left out and named with the reason.

The result is published on 2 November whether it is good or bad.

Who fixed it

The "fixed since our census" list names each fixed repository's publisher, what changed (from our scan rows), and a public link to the fixed image. It marks a fix "deliberate" only when the publisher's own public commits, in a window around the fix, change time-zone data; otherwise "rebuild" (a base-triggered or scheduled rebuild picked up fixed data). The rule was written before any fix was classified.

Changes before the freeze

The method was drafted on 18 October and changed in dated, append-only steps before the freeze. Most changes were written down before we applied them to any data. Some were corrections made after a read showed that the method had been wrong about an outcome we had already seen; those are not outcome-blind. The clearest case: on 23 October three Debian 13 images were fixed by rebuilds that our route rule said could not fix them, because their own build step upgrades or installs tzdata. We corrected the rule knowing those three outcomes (and three other rebuilds already read), then registered a test on later rebuilds: by the 24 October read, the Debian copy of all 15 Debian 13 images rebuilt after the correction was written was fixed or not fixed as the corrected rule said. The main changes: the frame query set was widened after a probe found repositories the first set missed; parents outside Docker Hub (a Prometheus base image, distroless) were read and their children routed through them; we found and corrected several of our own route errors as reads came in (Amazon Corretto on Amazon Linux 2023, Amazon Linux 2, the October OpenJDK release, which carries 2026e in its final builds and not in the earlier build tags we first read, and Debian 13 images that refresh tzdata in their own build step); observed events (Debian's acceptance of 2026e into trixie-updates on 22 October, Debian 12's security update on 23 October, the distroless update, the PHP, Node.js and Temurin releases) entered as facts; and the simulation window was corrected to start when we last saw each image wrong.

Limits

• One tag per repository, linux/amd64 only, Docker Hub only. Other tags, architectures and registries are not covered.
• "Default copy" is decided from where a copy sits and what the image contains, not from tracing what a running program loads.
• The 08:00 UTC equivalence is checked per tz release, not per vendor copy.
• Java tzdb.dat and ICU copies are judged from their tz release label, not their decoded offsets; a copy patched without changing its label, or relabelled without changing its data, would be misjudged.
• Copies the scanner does not recognise are not counted, so an image can carry a wrong copy we did not find.
• Rebuild rates come from 90 days of repository-wide push history, calibrated on 5.5 days of followed-tag moves; parent images we did not read may refresh in ways the routes do not show.
• The forecast says nothing about which images are deployed, or how many users run a wrong copy in a zone that matters to them.

Corrections

24 October 2026, after the freeze (independent review). No forecast number, fix call, route, rate or model input changed. The text above is the frozen text.

1. Rebuild history dates (step 3 of "How the forecast is made"). Step 3 says the community rebuild rate uses the 90 days before 19 October. That holds for 125 of the 138 community repositories in the model. The other 13 (9 of them maintained) were not in the 19 October history read, so their history was read on 24 October at 02:15 UTC, the read the forecast is built from, and covers the 90 days before then. The scale (29/41.3) and the pooled official rate (14 of 45 in 5.5 days) are the same for both groups. Official repositories use the pooled rate, so the date of their history does not enter their rate.
2. Copies the scanner cannot date. "Right" above means more exactly: the scanner judges no recognised default copy wrong. A recognised default copy whose tz release the scanner cannot determine (for example an ICU data library with no readable release label) is not judged, and does not make an image wrong. This applies to the count, the fix calls and the 2 November scoring alike. At the freeze-day read, 5 of the 923 scanned images were not counted wrong but carried such a copy; 3 of them are on the "fixed since our census" list, and their rows name it.
3. The maintained forecast (272, 90% interval 255 to 281) counts only images leaving through a published fix route. Images leaving through changes outside the route table, including images at the floor, and images becoming wrong are simulated for the whole frame but not split by maintained status. The maintained outcome can therefore fall outside that range, in either direction.
4. The fixed list. Each row now says the image has no default copy the scanner recognises judged wrong, and how each changed copy was judged (offsets measured, or judged from its tz release label). The earlier wording, "reads the right offsets in every default copy", claimed more than the scan shows. Docker Hub's page for an image digest shows the tag's newest push once the tag is pushed again, so it stops showing the digest we scanned. Such a row has no link, says so, and carries our own record of the scan of that digest (digest, read time, and every recognised default copy with its release, how it was judged and the verdict).
5. The page's data file. The page reads a public file derived from forecast.json. It leaves out our internal file layout and keeps the SHA-256 of the frozen forecast.json and of the model's input files; only the daily reads and the fixed list are rebuilt after the freeze. Every forecast number is the same as in forecast.json.