Cron and Daylight-Saving Time: Skipped and Repeated Runs

A cron expression describes wall-clock times such as 02:30. Daylight-saving time breaks the assumption that every wall-clock time happens exactly once. On two days a year in many timezones a local time is either missing or repeated, and a schedule that lands on it behaves in a way the expression itself does not define.

A time that does not exist

In America/New_York the clocks jump from 02:00 to 03:00 on Sunday 14 March 2027. There is no 02:30 that day. A job written as 30 2 * * * therefore has nothing to match on that date. A preview that simply skips the date is honest; one that invents a run is not. What your scheduler does is its own decision: it may skip the run, run it late, or run it at an unexpected time.

A time that occurs twice

On Sunday 7 November 2027 the same zone moves from 02:00 back to 01:00, so 01:30 happens twice, an hour apart. A job at 30 1 * * * can match both instants. Some schedulers run it once, some twice, and which one depends on the implementation and the time it happens to look at the clock.

Which jobs are affected

• Fixed daily times inside the changing hour (for example 02:30 in zones that change at 02:00).
• Hourly jobs are normally safe: the UTC spacing stays one hour, although one local hour is missing or repeated.
• Every-few-minutes jobs keep their UTC spacing; only the local labels shift.
• Jobs that must run once per local day are the most exposed, because that day is 23 or 25 hours long.

Not every day has 24 hours

A schedule of 0 9 * * * means 09:00 local every day, so the gap between two runs is 23 hours at spring forward and 25 hours at fall back. If you need a job exactly every 24 elapsed hours, a wall-clock schedule is the wrong tool. Use UTC, or an interval-based scheduler.

Practical advice

• Run critical jobs in UTC, which has no clock changes, and document the conversion for people.
• Avoid scheduling anything between 01:00 and 03:00 local time in zones that change clocks overnight.
• Make jobs idempotent, so running twice or late is harmless, and add monitoring so a skipped run is noticed.
• In Kubernetes set .spec.timeZone explicitly; in Spring set the zone attribute; do not rely on the server default.

Previewing clock-change days

The Cron Builder on DevCraftKit calculates run times from real timezone rules, never by adding 24 hours, and marks dates that hit a missing or repeated local time. It lets you choose whether a nonexistent time is skipped or shifted forward and whether a repeated time counts once or twice. Those are models for exploring the schedule: they cannot confirm what your scheduler will really do.

Conclusion

Cron expressions are wall-clock rules, and wall clocks are not perfectly regular. Decide deliberately which timezone a schedule uses, keep critical jobs away from the clock-change hours, and test the days when clocks change.