The Hour My Scheduler Loses Twice a Year

Every scheduled job I run lives in two clocks at once. I think about them in Pacific time, because that is the clock on my wall. The server runs them in UTC, because that is the clock cron reads. Somewhere between my head and the machine there is a conversion, and for a long time that conversion was a single number I had baked in by hand. Subtract the offset, write the UTC hour into the crontab, done.

A fixed offset between Pacific time and UTC is correct for exactly half the year. The other half it is off by sixty minutes, and the switch happens twice a year, quietly, on a Sunday at two in the morning, which is the worst possible time to notice anything.

UTC does not move. Everything I care about does.

UTC has no daylight saving time. It is a fixed reference and it never shifts. Pacific time is not fixed. From the second Sunday in March to the first Sunday in November it is daylight time, seven hours behind UTC. The rest of the year it is standard time, eight hours behind. Eastern time does the same dance on the same days, three hours ahead of Pacific the whole way through.

So when I encoded a six in the morning Pacific job as a fixed UTC hour, I did not encode a time. I encoded a time and a season. I picked one of the two offsets, frozen it into the crontab, and walked away. For the months where my chosen offset matches reality the job fires at six. For the other months it fires at five or seven, depending on which offset I happened to pick, and the wall clock I reason about and the wall clock the job runs on have come apart by an hour.

Why an hour matters when the market is the reference

If these were arbitrary jobs the drift would be cosmetic. They are not. The market opens at nine thirty Eastern, every trading day, year round, anchored to the Eastern wall clock and not to UTC. My pre-market scan is supposed to run an hour before that. My execution window sits just after the open. My daily Telegram update is meant to land at eleven in the morning Pacific, which is two in the afternoon Eastern, which is a specific point in the trading session.

All of those reference points move with daylight saving, because the market keeps wall-clock time. My UTC-pinned jobs do not move. So for one half of the year a job I think runs an hour before the open actually runs at the open, or thirty minutes into it. The scan I trust to be a pre-market scan has quietly become an opening-bell scan, and nothing in the logs says so, because from UTC's point of view the job ran exactly when it was told.

The fix is to stop converting

The mistake was doing the arithmetic myself. A fixed offset cannot represent a rule that changes twice a year, so any constant I write down is a snapshot of one season pretending to be a law.

The operating systems already know the rule. The time zone database ships the daylight saving transitions for every named zone, and it gets patched when governments change the dates, which they do more often than you would like. The correct move is to hand cron a named zone, America slash Los Angeles or America slash New York, and let it interpret the schedule in local time. Then six in the morning means six in the morning in March and in November, and the operating system absorbs the hour shift on the switch days so I never see it. The job stays pinned to the wall clock I actually reason about, instead of to a frozen offset that was only ever right for half the calendar.

The two days that still bite

Even after you stop converting by hand, the switch days themselves are sharp. In spring the clock jumps from one fifty-nine to three, so the two o'clock hour does not exist, and a job scheduled inside it either skips or slides depending on how your scheduler handles a time that never happened. In fall the clock falls back, so the one o'clock hour happens twice, and a job in that window can fire twice. If anything I run in the small hours is not safe to skip or to run twice, those two Sundays a year are exactly when I will find out.

So the rule I keep now is short. Schedule in the zone you think in, not in the zone the machine runs in. Let the time zone database carry daylight saving, because it was written by people who track every change and I am not. And keep nothing important scheduled in the one hour that disappears in spring or the one that repeats in fall, because those are the two hours my scheduler loses and finds, every single year, while I am asleep.