The job that drifts an hour, twice a year.
The clocks moved an hour. The job did not. Almost nobody can say why.
- The track
- Writes code
- The rep
- About thirty seconds
- Published
- September 2, 2026
The Exhibit
You have felt the small version of this already. The suggestion looks right, the tests are green, and the part of you that would have traced it never engages. A Microsoft Research survey of 319 knowledge workers put a shape on it: the more confidently people leaned on AI output, the less effort they spent actually comprehending and verifying it. The study.
Self-reported, so read it as a signal. But scale it across a team and a subsystem three people used to understand is now understood by one, and nobody decided that on purpose.
The study
Comprehension Debt
Comprehension debt: the gap between what gets shipped and what the team can still reason about.
The selfish reason to keep building the model anyway: being the only person who can explain the billing path is not job security, it is a pager that never stops. The model you can rebuild from scratch is the one that lets you hand the thing off and actually take the leave you are owed.
The idea
The Rep
Thirty seconds:
A scheduled job fires at 9pm nightly and is correct. Twice a year, for about a week, it fires at 8pm or 10pm. Why?
The answer
Daylight saving time. The job is almost certainly pinned to a fixed absolute instant: a cron running in UTC, or against a fixed offset like UTC+1. That instant fires at the same moment all year, but the local wall clock it lands on shifts by an hour when the region springs forward or falls back, so observed locally the 9pm job shows up at 8pm or 10pm until the next transition. (A schedule expressed in local time would hold at 9pm across the shift, though local-time scheduling has its own traps: the spring-forward hour that never happens and the fall-back hour that happens twice. The fixed-instant schedule is simply the one that produces this particular 9pm-to-8pm drift.) The fix is to schedule against an IANA time zone, Europe/Stockholm rather than UTC+1, so the runtime re-resolves 9pm local across the transition, while you still store timestamps in UTC. The week-long window is the tell: it is the gap between one region's DST change and another's.
About thirty seconds