Time zone scheduling
Store the schedule rule and the next occurrence separately
Preserve local intent so future executions can be recalculated correctly. A single timestamp cannot explain a recurring business schedule after an edit or time-zone change.
In this article
Capture the user's intended clock
Ask for the local time and business time zone when the workflow requires them. Show a readable zone label and a preview of upcoming occurrences.
Use a named IANA zone internally rather than a short abbreviation. Abbreviations can be ambiguous and do not describe the full rule history.
Keep date-only deadlines separate from timed events. Turning a business date into midnight in an arbitrary zone can change the displayed date elsewhere.
{
"scheduleId": "report-example-14",
"version": 3,
"localTime": "09:00",
"timeZone": "Australia/Sydney",
"recurrence": "weekdays",
"missingLocalTime": "nextValidTime",
"repeatedLocalTime": "once",
"missedExecution": "catchUpOnce"
}This illustrative policy is not a universal recommendation. The actual choices should match the task, and the scheduling implementation must support them.
Resolve and persist an occurrence
Use the supported time-zone library or scheduler to calculate the next instant under the chosen rules. Save an occurrence identity tied to the schedule version and intended execution.
Enforce uniqueness atomically so two scheduler instances cannot independently create the same occurrence. Keep worker attempts separate from the occurrence itself.
Record the resolved instant with an unambiguous offset or UTC representation for execution and diagnostics.
Apply edits with a clear boundary
When the user changes time or zone, version the schedule and decide what happens to already queued occurrences. Cancel or supersede them through a recorded state transition where appropriate.
Do not leave both old and new occurrences active unintentionally. A worker should verify that its occurrence remains valid before producing the effect.
Keep past execution records unchanged so history remains explainable.
Test preview against execution
Compare the UI preview with the scheduler's actual resolved times across daylight-saving boundaries. Use the same intent and policy, even if different components render it.
Restart the scheduler and retry a worker to verify occurrence identity. Then simulate a missed window and confirm the documented catch-up behaviour.
The implementation is ready when local intent, calculated time and actual execution can be traced as separate facts.
Primary sources
IANA: time-zone databaseAWS: EventBridge schedule typesReferences checked 11 September 2026.