A fixture built with toISOString fails an air-date test until Los Angeles catches up to UTC

The window is the offset itself. Between midnight UTC and roughly 07:00 UTC, UTC has already rolled over to a new date and Los Angeles has not ^[12]. A fixture that means "tomorrow in UTC" is therefore two days from the function's "today in Los Angeles" ^[11]. At 06:39 UTC on 12 September it is 23:39 on 11 September in Los Angeles, so UTC's tomorrow is the 13th and the show's today is the 11th ^[11]. Seven hours of the day while Los Angeles is on daylight time, eight when it is not ^[12], which works out to between 29 and 33 percent of every day red ^[19]. The shape transfers to any fixture trimmed with toISOString and compared against code that counts days in a named zone, and the failing window is as wide as the offset between the two ^[8][9].

The edited files were a privacy page, a footer and a markdown document ^[3]. The failing assertion covered air-date day counting ^[2]. `git stash && npx vitest run` produced the identical failure, and `git stash pop` put the work back ^[4]. The author wrote that calling a diff obviously unrelated is a hypothesis, and that checking it costs one command ^[5]. In my view that command belongs before reading your own diff in any repo with date fixtures, because the expensive outcome is "fixing" code of yours that was correct.

Day counting that fails intermittently points at timezones, so the next probe was the host zone: `TZ=Europe/Dublin` and `TZ=America/New_York`, both failing identically ^[6]. A useful negative. The host zone changes what the process calls local time, but it does not change the instant at which the test runs ^[6].

The fixture added multiples of 86400000 milliseconds to `new Date()` and trimmed the result with `toISOString().slice(0, 10)` ^[7]. toISOString always formats in UTC ^[8]. The function under test deliberately does not count in UTC; it counts in the show's own country's zone, which for a US show is America/Los_Angeles ^[9]. That choice was itself the fix for an earlier bug where a show's card and its notification disagreed about whether the same episode aired today or tomorrow, because one of them mixed the viewer's timezone into the comparison ^[10]. So in this failure the countdown was correct and the test was wrong ^[13].

This is worse than an ordinary red test. It presents as a feature bug, since a real off-by-one in the countdown would print the same 1 against 2 ^[14]. Re-running it later makes it pass, and according to the post that quietly teaches everyone the test is flaky and can be re-run rather than read ^[15].

The repair builds the fixture in the frame the function measures in: look up `ianaTimeZone` from `timeZoneData` where `iso_3166_1` is "US", then `DateTime.now().setZone(zone).plus({ days: n }).toISODate()` ^[16]. The zone comes from the same table the application uses, so the test does not hardcode a mapping that could later drift out of step with the code ^[17]. The post says as much: the test can no longer catch a wrong entry in that table ^[18].