Cron Time Zones and DST: Why Scheduled Jobs Run at the Wrong Time
Reviewed September 3, 2026 · Maintained by William
A cron expression does not contain all the information needed to answer “when will this job run?” The scheduler’s time zone is part of the answer, and daylight-saving transitions can make local wall-clock schedules skip or repeat.
Server time is often not your laptop time
A developer in Pakistan may test 0 9 * * * in a browser showing Asia/Karachi, then deploy to a Linux server configured for UTC. The expression is identical but the observed local time changes.
UTC is predictable, local business time is human-friendly
UTC avoids daylight-saving transitions and is often a good choice for infrastructure tasks. But a job that must run at “09:00 New York business time” has a different requirement: it should follow the local time-zone rules, including DST changes.
Spring-forward: a local time can disappear
In regions that advance clocks, a time such as 02:30 may not exist on the transition day. A scheduler can skip it, shift it or use implementation-specific behavior.
Fall-back: a local time can occur twice
When clocks move backward, an hour can repeat. A job scheduled inside that repeated interval may run twice unless the scheduler has safeguards.
Deployment checklist
- Record the intended time zone in the job documentation.
- Confirm the server/container scheduler’s configured zone rather than assuming it.
- If the job must follow a named region, use a scheduler that supports named IANA zones or handle the calculation in application code.
- Test the next transition dates for any schedule near the affected hours.
- Make jobs idempotent when duplicate execution would be damaging.
Browser calculator limitation
A browser tool can show matches using the browser’s time context, but it cannot know the production server’s cron daemon configuration. The Cron Next Run Calculator therefore presents its result as planning information and repeats the time-zone limitation.
Reference
crontab(5) documents cron timing behavior; consult your cloud or framework scheduler docs for provider-specific time-zone support.
Three clocks can be involved
A scheduled job can involve the developer’s local clock, the server or container clock, and the scheduler’s configured timezone. If you only look at the expression, you may miss which clock actually evaluates it. Record the timezone next to every important schedule.
Example: “run at 02:30 every day”
30 2 * * *In a timezone that jumps from 01:59 to 03:00 for daylight saving time, 02:30 may not exist on the spring transition day. In autumn, a local 01:30 or 02:30 can occur twice depending on the zone’s rules. Different schedulers make different choices about skipped or repeated wall-clock times.
Choose wall-clock time or elapsed time deliberately
“Run every day at 09:00 New York time” is a wall-clock requirement. “Run every 24 hours after the previous successful run” is an elapsed-time requirement. Those are not equivalent around daylight-saving transitions. Cron is naturally suited to wall-clock field matching; a queue/scheduler with interval semantics may be better for elapsed-time requirements.
UTC is useful, not magical
Running servers in UTC avoids DST jumps at the server layer and makes logs easier to correlate. It does not automatically solve business schedules such as “09:00 in the customer’s timezone.” For that requirement, store the intended IANA timezone (for example Europe/London), not just a fixed offset such as UTC+1, because offsets change.
Deployment checklist
- Identify which component evaluates the cron expression.
- Confirm that component’s timezone in the deployed environment.
- Check whether it supports a timezone directive or per-job timezone.
- Test dates on both sides of the next DST transition for relevant regions.
- Make repeated execution safe if an autumn transition can duplicate a wall-clock time.
- Monitor missed runs rather than assuming cron always executed successfully.
Debugging a job that “ran at the wrong time”
Start from timestamps in the scheduler and application logs. Convert them to UTC, then to the intended business timezone. Compare the server’s date/timezone configuration, container settings and scheduler-specific timezone options. If a cloud platform owns scheduling, its documented timezone behavior overrides assumptions based on the host shell.
The browser-based next-run tool can help visualize an expression, but its local display should not be treated as proof of the server’s timezone. Production verification belongs in the scheduler environment itself.