Why does injecting a fake clock not fix a Go test for a local-midnight log rollover that fails only on CI?

## The bug A daemon writes one file per local day and rolls over at midnight. Someone makes it testable by injecting `now func() time.Time`, the test passes on every laptop, and the nightly CI job fails — or worse, the job runs green for months and the rollover misfires once a year at 02:00. The injected clock fixed one input and left another hidden. ## A time.Time is an instant and a location `time.Time` carries a location pointer alongside the instant. The instant identifies a unique moment everywhere on Earth; the location decides what that moment is *called*. `Format`, `Year`, `Month`, `Day`, `Hour` and any "has the day changed" comparison are all answered in the value's location. So `time.Date(2026, time.March, 8, 4, 59, 0, 0, time.UTC)` is 04:59 in UTC and 23:59 on 7 March in New York. A rollover routine that formats it in one zone gets `2026-03-08`; in the other it gets `2026-03-07`. Both are correct; the test only pinned the instant. ## Where the machine leaks in Two doors. `time.Local` is the process's local zone, derived from the `TZ` environment variable or the host's configuration. Any call to `.Local()`, and any `time.Time` produced by code that used `time.Local`, is machine-dependent. Developer laptops are set to a city; CI containers are almost universally UTC. That difference is the whole failure. `time.Now()` returns a time in the local zone, so even production behaviour depends on the deployment host's zone unless the code says otherwise. ## The fix: the zone is a dependency too Treat the location the way you treated the clock — as a field, supplied once: ```go type Rotator struct { now func() time.Time loc *time.Location } func (r *Rotator) day() string { return r.now().In(r.loc).Format("2006-01-02") } ``` Production loads the zone the business actually means (`time.LoadLocation("Europe/Berlin")`, or `time.UTC` if the answer is "we roll over at UTC midnight, everywhere"). The test loads the same zone and drives the interesting instants: one minute before local midnight, one minute after, and the two transition days. Once the zone is explicit, the whole class of "works on my machine" failures disappears, because nothing in the path consults `time.Local`. ## Why setting TZ in the test is not the fix It is tempting to write `t.Setenv("TZ", "America/New_York")` and keep using `time.Local`. Two problems. The process resolves its local zone once and caches it, so a change made after anything has already looked at the local zone has no effect — which makes the technique work or not work depending on test order. And `TZ` is process-global: a test that changes it is incompatible with `t.Parallel()` and with every other test in the binary. An injected `*time.Location` is scoped to one instance and has neither problem. ## The missing zone database `time.LoadLocation` reads the IANA zone files from the host, falling back to the zone data shipped with the Go installation. A minimal container image often has neither, and `LoadLocation` returns an error — usually surfacing as a nil location and a panic in production rather than in the test. The standard-library answer is to blank-import `time/tzdata`, which embeds a copy of the zone database in the binary at a cost of a few hundred kilobytes, so `LoadLocation` succeeds wherever the binary runs. The alternative is to install the zone files in the image. Either way, this is a decision to make deliberately, not to discover from an on-call page. ## Not every local day is 24 hours The second half of the boundary problem. On the two DST transition days a local day is 23 or 25 hours long, so `t.Add(24 * time.Hour)` is not "the same time tomorrow" — it lands an hour early or an hour late, which is exactly how a rollover ends up producing two files for one day or none for another. Calendar arithmetic belongs to calendar functions: construct the next local midnight with `time.Date(y, m, d+1, 0, 0, 0, 0, loc)`, which normalises month and year ends for you, or use `AddDate(0, 0, 1)`. Duration arithmetic is for durations: timeouts, intervals, elapsed measurements. Mixing the two is the classic source of the once-a-year bug. ## What the test should actually cover With both the clock and the location injected, write table cases for the instants that matter rather than for a random Tuesday: the last minute of a local day, the first minute of the next, the spring-forward day when 02:00 does not exist locally, the autumn day when 01:30 happens twice, and a leap day. Each is a one-line `time.Date` in the fixture, runs in microseconds, and encodes the failure that would otherwise be found by the person carrying the pager.