Freezing the digest rules table as data, not the window object, stops an agent defaulting to UTC and inclusive bounds

04:10 UTC breaks a UTC default without any help. In America/New_York it reads 23:10 on the previous local day while the zone is on standard time, and 00:10 on the same local day once daylight time starts ^[1]. A filter that groups by UTC calendar day files that row under one date all year. One tenant and one event are enough to show it. The case study stays that small ^[5].

The second decision is the bound. The committed table says the window is half-open: `start_utc <= event < end_utc` ^[8]. The author writes that an unconstrained agent reaches for inclusive SQL `between` instead ^[4]. That is documented behaviour, and it is the wrong default here: two consecutive inclusive windows share their boundary instant, so a row landing exactly on the boundary is selected by both days' queries, while half-open bounds select it once ^[4]. Events at or after `end_utc` are labeled `late_for_this_window` and never silently merged ^[9].

A civil date keeps a generated change honest. US clocks spring forward on 8 March 2026, so that local Sunday lasts 23 hours ^[12]. Call `window_for_local_date` for America/New_York and 2026-03-08 and you get `start_utc` at 05:00 on the 8th and `end_utc` at 04:00 on the 9th ^[2]. An implementation that adds 24 hours to the start lands at 05:00 on the 9th and drags in the first local hour of Monday ^[3]. An event at 04:10 UTC on 9 March sits ten minutes past the real boundary, so the calculator calls it late, while a UTC-day filter counts it as the 9th ^[6].

The fail-closed path is short. `require_timezone` rejects None, the empty string and whitespace, then raises `MissingTimezoneError` ^[17], which subclasses `ValueError` ^[18]. `membership` raises on a naive datetime before it compares anything ^[20]. `Window` is a frozen dataclass, so a caller cannot move `end_utc` after the query has started ^[16].

The module holds no HTTP client, database handle or SMTP client ^[14]. The case study says agents fold date math into the worker, and asks reviewers to read the import graph as strictly as the date arithmetic ^[15]. A generated worker passes when it imports the calculator ^[22] and fails when it inlines local date arithmetic of its own ^[26].

The code is short enough to copy, but the published listing stops partway through `membership`, so the comparison logic and the pytest suite are left to the reader ^[27]. digest-window is labeled an exercise, not a production incident ^[2]. `window_id` ports cleanly into an existing system; for this tenant and date it is `America/New_York:2026-03-08` ^[5], and the table requires it in the log line and in the mail header ^[11].