Certificates & Site Ops · Field note
Cron and daylight saving time: what really runs twice, once, or not at all
Understand how daylight saving transitions affect cron schedules so recurring jobs stop surprising you every spring and fall.
Before you start
Inspect the current certificate, key, token, or endpoint output before changing deployment config; stale artifacts make fixes misleading.
Cron expressions are not wrong when DST creates weird behavior. They are literal schedules interpreted against a wall clock that changes. The surprise comes from forgetting that the wall clock itself is moving.
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.
Watch for: A human-readable cron translation is helpful, but it does not by itself answer how the scheduler behaves at transition boundaries.
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, that assumption can break. One local time may be skipped in spring or repeated in fall depending on the zone. That is not a parser problem. It is a calendar problem.
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 time zone explicitly. Review jobs near midnight and the DST transition window. For critical tasks, test the schedule against known transition dates rather than relying on memory. This is another example where a small utility plus one serious guide can save more pain than a long tutorial.
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?
Not always. Human-facing schedules often need local wall time, while infrastructure tasks often fit UTC better.