Cron Jobs and Time Zones: The Complete Reference
Cron jobs break when teams assume the server clock matches the business clock. Always name the execution timezone, then review what happens during DST changes.
Cron jobs stay reliable when you define the execution timezone explicitly and test what happens around DST changes. If you assume “midnight” means the same thing everywhere, the job will eventually surprise you.
Direct Answer
Cron jobs should use an explicit timezone or UTC. The dangerous version is a schedule that assumes the server clock and the business clock are the same thing.
The Safer Reference Table
| Situation | Better setup |
|---|---|
| Global backend jobs | Use UTC |
| Local business-hour task | Use explicit local timezone |
| DST-sensitive schedule | Test the transition window before release |
What To Check
- Which timezone the scheduler actually uses.
- Whether the job should run on UTC or a business city clock.
- What happens on the next DST transition.
Try it on a real schedule
The cron timezone drift checker renders the next runs of any 5-field cron expression in a chosen timezone and shows where a UTC-anchored schedule drifts across DST. It makes the classic trap concrete: a daily 02:30 job in America/New_York stays at 02:30 local all year under zone-anchored scheduling, but shifts to 03:30 local from mid-March to early November when the schedule is pinned to UTC.
Related Pages
- Cron timezone drift checker
- Unix timestamp converter
- ISO 8601: the one date format standard you need
- API overview and examples
Frequently Asked Questions
Should cron jobs default to UTC?
Usually yes, unless the business requirement is tied to a specific city clock.
What is the biggest cron and timezone failure?
Running a local-business-hour job from a server clock that nobody documented.
When should cron schedules be reviewed?
Before every DST transition that affects the execution timezone.