Why it matters
Twice a year the local clock skips an hour or repeats one. A job scheduled at 1:30am in London doesn't run on the last Sunday of March, because 1:30am never happens, and on a scheduler that watches the local clock it runs twice on the last Sunday of October. Whether that matters depends on the job and on the scheduler, and the rules are easy to forget.
This simulator takes a cron expression and a time zone, finds each clock change in the coming year from your browser's time zone database, and works out what happens on the day. It compares a scheduler that simply follows the local clock, cron(8) as its manual describes (Vixie cron and cronie run a skipped fixed-time job soon after the change and don't repeat one in the doubled hour), and the same job on a server set to UTC. Explore the expression itself with the cron expression explainer.
How to use it
- Type a cron expression.
- Choose the server's time zone.
- Read what happens at each clock change.
- Move the job outside 1am to 3am, or run the server in UTC, if a skipped or doubled run would hurt.
FAQ
What happens to cron jobs when the clocks go forward?
Local times in the skipped hour don't exist. A scheduler that follows the local clock misses those runs; cron(8) runs fixed-time jobs from the skipped hour soon after the change.
Will my cron job run twice when the clocks go back?
On a scheduler that follows the local clock, yes, for times in the repeated hour. cron(8) doesn't re-run fixed-time jobs then, but jobs with * in the minute or hour field do run again.
How do I avoid DST problems in cron?
Run the server in UTC, or schedule jobs outside the hours that change (usually 1am to 3am local time).
Where do the clock change dates come from?
Your browser's built-in time zone database (the same IANA data operating systems use).
