Cron at 9am: timezones and daylight saving
A 9am job, a clock change, and the three timestamps worth checking before you deploy.
A weekday job runs at 9am all winter. Then the clocks change, and it starts arriving at 10am. The cron expression may be perfectly valid: the scheduler was following UTC while you were expecting local time.
Before copying a schedule into a service, decide which clock it should follow. A daily report for a Melbourne team and an hourly backup do not necessarily want the same rule.
The timezone is not in the expression
This five-field expression means 09:00, Monday through Friday:
0 9 * * MON-FRI
It does not say where 09:00 is. The scheduler supplies that part. In CozyToolkit's cron builder, choosing a timezone changes the preview; it does not add a timezone to the expression you copy.
If your hosting service supports a named timezone, use one such as Australia/Melbourne. A fixed offset such as UTC+10 cannot follow Melbourne's seasonal clock changes.
Three runs across a clock change
We previewed that expression in Australia/Melbourne, starting at midnight on 2 October 2026. These are the next three weekday runs:
| Melbourne time | UTC time |
|---|---|
| Friday 2 October, 09:00 (UTC+10) | Thursday 1 October, 23:00 |
| Monday 5 October, 09:00 (UTC+11) | Sunday 4 October, 22:00 |
| Tuesday 6 October, 09:00 (UTC+11) | Monday 5 October, 22:00 |
The local hour stays at 9am. The UTC hour changes. If we instead set the preview to UTC, the same expression produces 09:00 UTC on those weekdays—19:00 in Melbourne on Friday and 20:00 on Monday.
You can download the schedule and both sets of timestamps. The dates in that file are ISO timestamps; the trailing Z means UTC.
Reproduce the preview
- Open the cron builder and choose Paste expression.
- Paste the expression above into Cron expression.
- Set Schedule timezone to
Australia/Melbourne. - Set Preview after to 2 October 2026 at 00:00. The date and time use the timezone you selected.
- Check Upcoming runs. On a phone, switch from the schedule tab to the upcoming-runs tab.
- Change the timezone to UTC and compare. Recheck the preview start date too: the control displays the same instant in the newly selected timezone.
This previews dates; it does not create or run a scheduled job. Set the timezone again in the service that will execute it.
If your scheduler only uses UTC
Cloudflare Cron Triggers run in UTC. Copying the expression above into a Worker will therefore schedule 09:00 UTC, regardless of the timezone you used in our preview.
For a local-time requirement, you need a deliberate solution: a scheduler with named-timezone support, seasonal schedule changes, or a more frequent trigger whose application checks the local date and hour and records whether that day's job has already run. A fixed UTC schedule alone will not stay at 9am in a city that changes its clocks.
There is another portability trap: weekday numbers differ between cron implementations. Cloudflare uses 1 for Sunday; our builder uses the common 0-for-Sunday convention. Use weekday names such as MON-FRI when the destination supports them, and check its documentation before deploying.
Check the awkward dates before shipping
Preview the week on each side of a daylight-saving change. For monthly schedules, also check February and months without a 31st.
An early-morning time such as 02:30 can disappear or occur twice when clocks change. Different schedulers can handle that differently. Decide whether to skip, delay or deduplicate the job, then test the actual service. A preview from another parser is not a guarantee of its behaviour.
On 1 October 2026, we checked these timestamps using the same timezone-aware parser as the tool and verified the corresponding local times. The test results record the inputs and outputs. No scheduled job was deployed for this example.