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.
Related Pages
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.