Time zone scheduling
Recover local intent before replacing fixed-offset schedules
Existing UTC timestamps may not reveal what users originally meant. Classify schedules before converting them to named-zone recurrence rules.
In this article
Identify the old semantics
Determine whether each schedule represents an absolute instant, an elapsed interval or a recurring local time. They should not all be converted the same way.
A one-off appointment already agreed at a specific instant differs from a daily 9 am site report. Preserving one may require retaining the instant, while preserving the other requires recovering local intent.
Use original user input or business configuration where available. A stored offset alone may not identify the intended location.
Resolve ambiguous schedules
Create a review path for records whose zone or recurrence cannot be established reliably. Do not guess a zone from a current IP address or an operator's location.
Show the old and proposed upcoming occurrences to the responsible user or business owner. Concrete dates and times make a shift easier to detect than a technical zone identifier alone.
Record the decision and provenance for the conversion.
Run both calculations before switching
Calculate future occurrences under the old and new models without executing both. Compare across a representative period that includes relevant clock transitions.
Investigate intended and unintended differences separately. A corrected daylight-saving shift should be explained, while an accidental one should block the affected migration.
Test date-only tasks and schedules spanning different Australian zones.
Transfer execution ownership once
Version the new rule and supersede or cancel old queued occurrences under the documented policy. Prevent both schedulers from creating independent work for the same business occurrence.
Verify restart, retry and missed-window handling after the switch. Keep the old calculation evidence for investigation without allowing it to resume execution accidentally.
The migration is complete when users' intended timing is preserved or deliberately corrected, and each occurrence has one coherent execution path. Converting every timestamp with one timezone function cannot establish that result by itself.
Primary sources
IANA: time-zone databaseReferences checked 11 September 2026.