How do you decide whether Go services embed time/tzdata or rely on the image's zoneinfo?

## What is actually being decided A Go binary that renders local times needs the IANA time zone database at run time. It can come from inside the binary or from outside it, and that is a decision with an owner, a cost and a failure mode — not a style preference. Two teams have a claim on it: the service team that ships the binary and gets paged when appointments are an hour out, and the platform team that owns the base image and would like to patch zone data centrally. Spell out the three postures before arguing about them. ### Posture 1 — embed the database `import _ "time/tzdata"` in the `main` package embeds a full copy, roughly 450 KB, used whenever system zone files are absent. - **Pro:** the binary is self-contained. It behaves identically on a laptop, in CI, and in a minimal image with nothing else in it. Zone behaviour becomes a property of the artefact you tested, which is the strongest argument in its favour. - **Con:** the embedded copy is fixed at build time and travels with the Go release you built with. A country moving its DST rules means updating the toolchain and rebuilding — the service team's work, on the service team's release cadence. - **Note:** the guidance is explicit that `main` imports it and libraries do not, so this is a per-binary decision by design. ### Posture 2 — rely on the image The base image ships an OS zone package; the binary just calls `time.LoadLocation`. - **Pro:** binaries stay small, and zone data can be refreshed by rebuilding images — no application release, no toolchain bump, and one team can do it for the whole fleet. - **Con:** it is an undeclared dependency. Nothing in the repository states that the image must contain zone files, so a slimming change to the base image removes them and every service quietly renders UTC. The blast radius is the whole fleet and the signal is zero. ### Posture 3 — pin your own data `//go:embed` a database or the specific zones you need and build locations with `time.LoadLocationFromTZData`. - **Pro:** the exact bytes are under version control and reviewable; the binary stays small if you ship only the zones you support. - **Con:** you now own sourcing, verifying and refreshing that data, and any zone outside the set fails. Worth it when the set of zones is genuinely small and fixed, or when auditability of the data matters. ## The questions that decide it **How wrong can a stale or missing zone be for this product?** For a scheduling service the answer is "an hour, silently, for a subset of users" — bad enough that reproducibility beats central patching, which argues for embedding. For a service that only formats logs, UTC everywhere is fine and the whole discussion is moot. **Who can ship a fix, and how fast?** Governments change DST rules with weeks of notice. If your release cadence is daily, embedding is fine; if a rebuild takes a change-approval window, the image route puts the fix in the hands of a team that can move. **Can the dependency be made visible?** Posture 2 is defensible only with an explicit contract — the image documents that it ships zone data, and something in the build or a startup check proves it. Without that, the platform team can break every service without knowing the dependency existed. **How much does 450 KB cost here?** Usually nothing. Argue about it only where image size or memory per instance is a measured constraint, not as a reflex. ## The parts that are not a trade-off A few things hold whichever posture wins, and they are what actually stops the outage: - **Fail at startup.** Load every zone the service can be configured with at boot and refuse to start if one fails. There is no useful degraded mode for a service that renders local times. - **Never substitute UTC on error.** Silent fallback converts a loud failure into wrong data that looks right. - **Test the failure.** A test with `ZONEINFO` pointed at a nonexistent path exercises the error branch; running the release artefact in its own image catches the missing-database case where it actually happens. - **Keep libraries out of it.** Shared packages report zone errors upward; only the binary's `main` decides where data comes from. ## Writing it down The deliverable is a one-line default with a stated exception, not a document: *services that render user-local time blank-import `time/tzdata` in `main` and validate their zones at startup; services that only emit UTC do neither.* Put the check in the shared build so drift is caught mechanically, and agree with the platform team which posture the base image is expected to support — because the failure of an unwritten assumption here is discovered by a user, the morning after a transition, and never by a test.