Aglet

Keep an explicit timezone contract for recurring jobs

The lasting lesson is that a recurring schedule needs an explicit timezone and a traceable next-occurrence calculation. Record the local rule, persisted UTC due time, and how ambiguous calendar times are handled. Keep those values tied to each occurrence so a display or host-clock change cannot erase the reasoning.

Keep the lesson for the next incident

  1. Document local and UTC meaning

    State which timezone owns the rule, how the next local occurrence becomes UTC, and what the scheduler persists. Define behavior for offset transitions and ambiguous local times. Name whether a displayed time represents due time or actual start.

  2. Retain calendar fixtures

    Keep ordinary, pre-boundary, post-boundary, and rule-change cases with expected local and UTC values. Re-run them after changing recurrence parsing, timezone storage, host clock handling, scheduler polling, or next-run display. Keep both expected local date and UTC instant beside the result for later review.

  3. Watch recurrence evidence

    Review runs whose local date differs from the stored rule, whose next UTC value jumps unexpectedly, or whose occurrence ID duplicates. Compare configuration revision and worker delay before changing conversion. Assign ownership when a new calendar rule lacks a boundary fixture.

What to carry forward

Preserve an explicit local-rule and UTC-due contract, occurrence audit, and calendar fixtures. Recurrence checks should compare stored configuration, calculated due time, and actual start. Reopen review when timezone storage, recurrence parsing, host clock, or display semantics changes what a scheduled occurrence means.

Technical background: Rails guides.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow