Time zone scheduling
A scheduled job ran an hour late
Compare the stored local rule, named zone and resolved instant before changing the server clock. The error may be in interpretation, queueing or display.
In this article
Find the schedule version
Locate the schedule definition and occurrence record used for the run. Record local time, zone, resolved instant and actual execution timestamps.
Check whether the user edited the schedule or changed the business location recently. An old queued occurrence may still be valid under one policy or should have been superseded under another.
Do not infer the intended zone from the investigating operator's device.
Separate timing from presentation
Compare the UTC execution instant with the expected local occurrence. A display formatted in the wrong zone can look late even when execution was correct.
If the resolved instant is wrong, inspect fixed offsets, ambiguous abbreviations and time-zone data versions. If it is correct but execution is late, inspect queue and worker delay.
Changing infrastructure time settings without this distinction can create a second problem.
Check the transition policy
Determine whether the occurrence fell in a daylight-saving gap or repeated interval. Compare the observed behaviour with the documented business rule and scheduler semantics.
A daily rule implemented as a fixed elapsed interval may shift local clock time across a transition. Correct the schedule model rather than adding an unexplained seasonal offset.
For a missed occurrence, apply the catch-up policy separately. Do not rerun an obsolete notification merely to make a dashboard look complete.
Repair future and past work deliberately
Recalculate future occurrences under the corrected rule and supersede old queued work as required. Preserve historical records so the cause remains visible.
Review whether the late execution created a business consequence that needs separate handling. Keep duplicate protection if a controlled rerun is appropriate.
Add the exact boundary or edit sequence to regression tests. The incident is resolved when the next occurrences are correct and the affected past work has an explicit outcome, not just when one timestamp has been manually adjusted.
Primary sources
IANA: time-zone databaseAWS: EventBridge schedule typesReferences checked 11 September 2026.