# Nine each morning is not a fixed UTC interval

A local business schedule needs a named time zone and explicit daylight-saving behaviour. Store the user's intent before calculating individual execution times.

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

## Distinguish a local rule from an instant

A reminder for 9 am in Sydney each weekday is a recurring local rule. A reminder at a particular UTC timestamp is one instant. Repeating the first by adding 24 hours to the previous instant can shift its local clock time across a daylight-saving transition.

Store the local time, named zone and recurrence separately from calculated occurrences. Use an IANA zone such as Australia/Sydney rather than a fixed offset that cannot express future seasonal changes.

The IANA database is updated as civil-time rules change. Keep the runtime's time-zone data maintained and decide how future calculated occurrences are refreshed after an update.

## Make the Australian distinction visible

Queensland does not observe daylight saving, while New South Wales does, subject to its local rules and exceptions. A Brisbane-based operator scheduling work for Sydney should see which location's clock controls the task.

Do not infer the business zone solely from the operator's device. They may travel or manage several sites. The schedule belongs to the intended business location unless the product explicitly defines another model.

### A local schedule produces identifiable occurrences

The application preserves local intent and zone rules, then records each resolved occurrence so retries do not create a second execution.

1. **Business rule**: Save local time, named zone and recurrence
2. **Time resolution**: Apply zone data and gap or overlap policy
3. **Occurrence record**: Persist resolved instant and unique execution identity
4. **Worker outcome**: Execute or record missed-work handling under policy

## Decide what happens to unusual local times

When clocks move forward, some local times do not occur. When they move back, some occur twice. The product needs a policy for a schedule landing in either interval.

For example, a maintenance task might skip a nonexistent occurrence, while a daily business report might run at the next valid time. A repeated clock time might run once or twice depending on the intended rule. Do not let a library's default silently make that business decision.

Managed schedulers have their own documented behaviour. Verify it before assuming it matches the application's promise.

## Give each occurrence a stable identity

Separate the schedule definition from each due execution. A retry should continue the same occurrence, and a scheduler restart should not create another independent job for it.

Record the schedule version and intended local occurrence as well as the resolved instant where useful. This helps explain what happened after a user edits the rule or time-zone data changes.

## Handle missed work deliberately

If the service is unavailable at the scheduled time, choose whether to catch up, skip or request review. An old notification may no longer be useful, while a required reconciliation job may still need to run.

The design is complete when the user can understand the next occurrence and the operator can explain duplicates, missed times and daylight-saving boundaries without guessing from a bare timestamp.

## Sources

- [IANA: time-zone database](https://www.iana.org/time-zones)
- [NSW Government: daylight saving](https://www.nsw.gov.au/about-nsw/daylight-saving)
- [AWS: EventBridge schedule types](https://docs.aws.amazon.com/scheduler/latest/UserGuide/schedule-types.html)