Fixed time inside a daylight-saving transition

Twice a year, in zones that observe daylight saving time, the local clock jumps. In spring it skips forward — 02:00 to 03:00 vanishes — and in autumn it repeats an hour, so 01:30 happens twice. A cron job scheduled at a fixed minute inside that window inherits the ambiguity.

On the spring-forward day, a job set for 30 2 * * * (2:30 AM) never runs, because 2:30 does not exist that day. On the autumn fall-back day, the 1 AM hour occurs twice, so a 1:30 job can fire twice. Neither outcome is what "run once a day" implies, and both are notoriously hard to reproduce because they only happen on two specific dates.

This warning fires when the hour field resolves to a value between 1 and 3 and the minute is a fixed number rather than *, in a schedule time zone that actually changes its clocks. Zones without DST — UTC, America/Port_of_Spain, most of Asia — are unaffected, and the rule stays quiet for them. Set the schedule time zone in the tool to see the difference.

There are three good fixes. The simplest is to move the job out of the transition window: 30 4 * * * or 30 0 * * * run on every ordinary day and are unaffected by the shift. The most robust is to run the schedule in UTC, which never changes, and convert in your head or your tooling. If the job genuinely must run at a local wall-clock time and you accept the twice-a-year wobble, at least document it so the next person is not debugging a "missing" run in March.

GitHub Actions sidesteps this entirely by running only in UTC — which is also why a 9 AM local schedule there drifts by an hour half the year.