# 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.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## 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.

## Sources

- [IANA: time-zone database](https://www.iana.org/time-zones)