Duplicate runs across a DST boundary

Recurring work scheduled in local time ran twice on the autumn transition and not at all on the spring one.

2026-06-02 · scheduler · closed

What actually happened

Schedules were stored as local wall-clock times and expanded against the local zone at dispatch. An hour that occurs twice produces two dispatches; an hour that does not occur produces none. Both had been true since the scheduler was written and neither had been noticed, because the affected window is two hours a year and the jobs in it were idempotent by luck rather than by design.

It surfaced when a non-idempotent job — a monthly rollup that appends — was moved into the affected window.

What we changed

• Schedules store a zone alongside the time, and expansion happens in UTC. Shipped 2026.9.1.
• Existing schedules were migrated with the zone they were assumed to have. Three were ambiguous and were confirmed with their owners rather than guessed.
• Dispatch is keyed on the resolved UTC instant, so a duplicate expansion collapses instead of firing twice.

Note on the migration

The three ambiguous schedules are worth recording: all three were created before the scheduler had an owner field, and the only way to establish intent was to ask who ran them. That is the argument for the owner field, made retroactively.