Certificates & Site Ops
Cron and Daylight Saving Time
Understand how daylight saving transitions affect cron schedules so recurring jobs stop surprising you every spring and fall.
A cron expression follows a wall clock that can skip or repeat local times during DST transitions.
The fix is to think about local-time recurrence and UTC execution as separate layers.
In brief
What it is: Cron schedules describe recurring times against a clock context, and daylight saving transitions change the mapping between local wall time and absolute time.
Why it matters: If a local time disappears or repeats during a DST change, the corresponding job behavior changes too.
Worth knowing: Pair a human-readable cron translation with the scheduler's documented time-zone and DST behavior.
Why the same expression behaves differently across the year
A schedule like “2:30 AM every day” assumes that 2:30 AM exists once every day in the configured time zone. During DST transitions, one local time may be skipped in spring or repeated in fall depending on the zone. The scheduler's calendar and time-zone behavior determines the result.
Once you say that out loud, the next question becomes practical: should the schedule follow wall time or absolute UTC time?
Human meaning vs execution reality
Many business schedules are meant to follow local human time: start of business day, weekday quiet hours, office opening, and so on. For those, the time zone choice matters more than the cron syntax itself. Other jobs are better anchored to UTC because they are infrastructure tasks where local-clock meaning is not important.
A cron translator can help explain the pattern, but a better workflow also surfaces the execution zone and DST risk.
- Use local wall time for human-facing schedules.
- Use UTC when absolute cadence matters more than local meaning.
- Review DST edge cases for jobs scheduled near transition hours.
How to prevent the annual surprise
Write down the scheduler's time zone. Review jobs near midnight and daylight-saving transitions, then test critical schedules against known transition dates.
See it in a small example
Notice: Cron syntax did not change. The clock context did.
Local wall-clock schedule + DST boundary = possible skipped or repeated local run time
What to verify
- Write down the scheduler time zone explicitly.
- Review jobs scheduled near known DST transition hours.
- Decide whether the job follows local wall time or absolute UTC cadence.
Common questions
Can cron itself prevent DST surprises?
Cron syntax alone cannot solve the underlying time-zone semantics. Scheduler behavior and time-zone choice matter.
Should everything just run in UTC?
Human-facing schedules often need local wall time, while infrastructure tasks often fit UTC better.
