DST collision simulator
Twice a year the clocks change. Paste your schedules and see which jobs fall into the hour that vanishes or the hour that happens twice, with what each scheduler actually does about it.
What each scheduler does
| Scheduler | Clocks go forward | Clocks go back | Source |
|---|
“Documented” means the official docs say so; “reported” means community reports only; “not documented” means we found nothing to cite. Always test with your own scheduler and zone.
The two bad hours
Daylight saving time creates two awkward moments each year in most of North America, Europe and Australia. In spring the clocks jump forward and one hour of wall-clock time does not exist. In autumn they move back and one hour exists twice. A schedule written in local time, such as "run at 02:30 every night", lands directly in those hours on the affected nights.
What happens next depends on the scheduler. The job may be skipped, run late, run immediately afterwards, or run twice. Vixie cron documents that jobs from the skipped interval run immediately after the change and that it avoids running a job twice in the repeated hour, but only for jobs that run at a specific time or less than hourly. Others, such as node-cron, document that the repeated hour runs once and sub-hourly schedules can pause. For many (Spring, Kubernetes) the documentation says nothing at all.
The simulator evaluates your actual schedules against the real transition dates for each zone, shows the time window on a timeline with your jobs marked, and lists the affected run times. It deliberately labels the worst case, not a promise about your scheduler, and cites the documentation where it exists.
Frequently asked questions
What happens to a job scheduled during the hour that is skipped?
When clocks jump forward (for example 02:00 to 03:00) the times in between never occur. What a scheduler does with a job due in that hour depends on the scheduler: vixie cron runs it immediately after the jump, node-cron and others skip it, and Quartz is reported to shift it. The simulator shows the worst case and what each scheduler's documentation says.
What about the hour that happens twice?
When clocks move back (for example 02:00 to 01:00) the hour from 01:00 to 02:00 occurs twice. A naive scheduler may fire a 01:30 job both times. Cron implementations such as vixie cron avoid running it twice; others do not say.
How do I avoid the problem entirely?
Run time-critical jobs in UTC, which has no daylight saving, and convert for display only. If a job must follow local time, avoid the one or two hours around the change in your zone, and make the job idempotent so a repeat or a late run is harmless.
Why does it say "not documented" for some schedulers?
Because the official documentation does not describe it, and we do not guess. Where we could only find community reports, the tool says "reported". Write a small test with your scheduler and zone if the answer matters.