Aglet

Investigate scheduled timezone drift across a calendar boundary

Investigation should compare calendar interpretation rather than relying on a single timestamp. Use a fixed recurrence and timezone across an ordinary date and the reported boundary. Trace persisted configuration, calculated due time, scheduler polling, and actual start; keep host clock and presentation transformations visible.

Build a useful investigation brief

  1. Create paired recurrence cases

    Prepare sanitized schedule records for an ordinary date, the date before the boundary, and the date after it. Record intended local times and expected UTC instants using an independent reference. Keep the rule and timezone revision fixed for the first replay.

  2. Trace due-time computation

    Follow the rule from storage through local-to-UTC conversion, next-occurrence persistence, scheduler read, enqueue, claim, and start. Compare each value with the independent expectation. If a due timestamp is correct but the start is late, narrow the brief to worker availability.

  3. Test persisted zone semantics

    Exercise one candidate correction that stores or reads the explicit timezone and recomputes the next occurrence from the rule. Compare ordinary and boundary cases, including the displayed local time. Keep any ambiguous local-time policy as a separate decision rather than silently choosing one.

What to carry forward

Deliver paired recurrence values, stored rule and zone, first conversion divergence, and one boundary comparison. State whether the next work belongs to configuration, calendar conversion, scheduler delay, or display. Preserve ambiguity for local times that the current contract does not define.

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