Cron, DST and Time Zones: Skipped and Doubled Runs
Cron matches the wall clock of the daemon's time zone. Twice a year in a zone with daylight saving that clock does something that a fixed 30 2 * * * did not plan for. The time-zone tool shows both days for any zone.
Spring forward: a time that does not exist
In America/New_York on 2026-03-08 the clock jumps from 02:00 to 03:00, so 02:30 never happens. The tool lists that run as skipped, and the sequence for 30 2 * * * goes 06 March, 07 March, 09 March. Whether a given daemon skips the job, runs it at 03:00, or runs it late is implementation-dependent; the tool reports the strict reading, "the wall time did not occur".
Fall back: a time that happens twice
On 2026-11-01 the clock returns from 02:00 to 01:00, so 01:30 occurs twice, once at UTC-04:00 and once at UTC-05:00. The tool counts it once, at the first occurrence. Some daemons run the job twice. Test yours on a day it matters, or read its documentation.
Choosing a schedule
| Approach | Effect |
|---|---|
Run in UTC (CRON_TZ=UTC where supported, or a host set to UTC) | No gap, no repeat |
| Schedule outside the 01:00 to 04:00 window of the zone | The transition cannot touch it |
| Make the job idempotent | A double run is harmless |
Use a systemd timer with Persistent=true | A missed run happens on the next opportunity |
TZ and CRON_TZ
TZ= in a crontab sets the environment of the commands, not the schedule. Some daemons (cronie, for example) honour CRON_TZ= for the schedule; others ignore it. Check your daemon's man page before relying on it.