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.
Tip
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.
Summary
Definition: 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.
Pitfall: 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.
Quick example
Use this when a local-time schedule sits near the hour that changes during DST transitions.
What to notice: Cron syntax did not change. The clock context did.
Local wall-clock schedule + DST boundary = possible skipped or repeated local run time
Practical check
- 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.
FAQ
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.
Developer workflow
Use this guide as an operations checklist before changing certificates, tokens, DNS, or deployment settings.
- Inspect the current artifact or endpoint output before making changes.
- Change one variable at a time so a failed verification has a narrow cause.
- Keep the rollback value, expiry, and verification command in the same runbook entry.
1. current deployed artifact
2. single config or key change
3. verify endpoint/client behavior
4. record rollback and expiry details