Aglet

Triage scheduled timezone drift from local rule to UTC run

A recurring job can move because its configured zone was changed, its calendar rule was interpreted differently, or a local offset transition was converted incorrectly. Triage one unexpected occurrence and a neighboring expected occurrence. Keep the local rule, UTC due timestamp, and actual start as separate facts.

Establish what is happening

  1. Record the schedule inputs

    Capture schedule ID, recurrence rule, configured timezone, intended local date and time, persisted due timestamp, and the clock used to calculate it. Include the application or operator view of the next run. Do not reconstruct the intended time from the observed start.

  2. Compare neighboring occurrences

    Place an ordinary-date occurrence beside the occurrence near the reported offset or calendar boundary. Compare local display, computed UTC, enqueue, claim, and start times. If only the display moved while UTC remained stable, separate presentation drift from scheduling drift.

  3. Find the first conversion break

    Identify where the local rule becomes a due timestamp and where the scheduler reads it. Check persisted zone data, host clock, and any serialized recurrence fields. Mark missing zone information or ambiguous local times as evidence gaps rather than assuming daylight behavior.

What to carry forward

Return the schedule rule, configured zone, local and UTC due values, host clock, neighboring comparison, and first conversion divergence. Classify the scope as stored configuration, calendar conversion, scheduler read, or display. Keep the run unexplained when the original zone or rule revision is missing.

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