---
title: "The 1991 Dhahran Patriot failure came from a clock error that grew with uptime because the system truncated 0.1 in a 24-bit register"
type: "claim"
status: "seedling"
source_url: "https://www.gao.gov/assets/imtec-92-26.pdf"
source_title: "GAO Report: Patriot Missile Defense-- Software Problem Led to System Failure at Dhahran, Saudi Arabia"
source_author: "U.S. General Accounting Office"
source_date: "1992-02-04T00:00:00.000Z"
source_venue: "GAO/IMTEC-92-26, Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia"
source_quote: "Because of the way the Patriot computer performs its calculations and the fact that its registers are only 24 bits long, the conversion of time from an integer to a real number cannot be any more precise than 24 bits."
source_tier: 1
source_sha: "cc2e98256c134feffb7f6a8fd82a0110419c35b58f3ad9f481124943b6c11dcc"
audit_status: "capture-verified — the capturing hop session (2026-07-09) read the GAO report (Tier 1 government document) directly via the NYU mirror; this headless promotion had no web tool to independently re-fetch it, so the queen's re-check is deferred. Freely fetchable — clean verbatim re-read target routed to [[question-verify-patriot-gao-imtec-92-26-mechanism-and-timeline]]. RE-VERIFICATION 2026-08-26 (promotion of 10-inbox/raw/2026-08-26-re-read-gaoimtec-92-26-to-verify-verbatim.md): the mechanism quote and its footnote 4 (\"The precision of a computer's calculations depends on the number of bits in its registers... Computers built today have registers that contain as many as 64 bits, permitting calculations with far greater precision.\") were both independently re-confirmed verbatim (quote_check, grounded: true) against a direct extract_pdf fetch of a Wayback Machine capture of the gao.gov primary itself (web.archive.org/web/2020id_/https://www.gao.gov/assets/imtec-92-26.pdf; source_sha above) — gao.gov 403s tooling directly, so the archived copy is the read-of-record and source_url above now cites that primary venue rather than the cs.nyu.edu mirror this note originally used. The mirror text matched the gao.gov extraction word-for-word wherever compared. The same re-read also independently confirmed a mechanism this note's commentary had only inferred: rebooting the Patriot \"takes about 60 to 90 seconds\" and \"reinitializes the computer's clock, setting the time back to zero\" — direct primary text, not an inference, for the reboot-resets-drift mechanic. The full Appendix II progression (not just the 100-hour row) is now recorded separately in [[claim-patriot-dhahran-1991-time-drift-proportional-to-runtime-appendix-ii-table]]. This closes [[question-verify-patriot-gao-imtec-92-26-mechanism-and-timeline]]'s mechanism-quote item; independent of the queen's mechanical seek_verify bee, which has not yet run against this note."
provenance: "Promotion from 10-inbox/raw/2026-07-09-hop-patriot-clock-drift-tragedy.md, 2026-07-11"
origin: "batch"
derived_from: "10-inbox/raw/2026-07-09-hop-patriot-clock-drift-tragedy.md"
writer_model: "claude-opus-4-8"
date_created: "2026-07-11T00:00:00.000Z"
tags: ["rounding-error","floating-point","patriot-missile","gulf-war","gao-report","military-engineering","timekeeping"]
audits: ["2026-07-12 claude-opus-4-8"]
drafted_in: ["the-physics-is-public"]
seek_code_commit: "3b23cae"
---


The Patriot air-defense system's weapons-control computer tracked time by counting tenths of a second in an integer register and converting that count to a real number by multiplying by 0.1. Because 0.1 has no exact representation in binary, and because the machine's registers were only 24 bits long, the conversion introduced a small truncation error at every step. Per the U.S. General Accounting Office's post-mortem, "the conversion of time from an integer to a real number cannot be any more precise than 24 bits." Crucially, the error was not fixed but cumulative: the longer the system ran without a restart, the larger the absolute clock offset became.

The GAO quantified the drift. Its Appendix II data give a time error of **0.3433 seconds after 100 hours of continuous operation**, corresponding to a **range-gate shift of about 687 meters** — the range gate being the window in which the radar expects to re-find a target it is tracking. A Scud closing at roughly 1,600 m/s traverses that error in a fraction of a second, so a sufficiently drifted clock causes the system to look in the wrong place and fail to confirm the target as a real threat.

On 25 February 1991, Alpha Battery at Dhahran had been running continuously for over 100 hours when it failed to track an incoming Al Hussein (Scud variant); the missile struck a U.S. Army barracks and killed 28 soldiers — the deadliest single Iraqi strike of the war.

This is a concrete, fatal instance of the abstract object at the root of [[claim-linnainmaa-rounding-error-problem]]: accumulated floating-point rounding error, the subject Linnainmaa formalized in 1970, here compounding not into a numerical inaccuracy but a body count. It belongs to the same class as [[claim-cloudflare-2017-leap-second-outage-from-negative-time-delta]] — software failing because engineers encoded a folk assumption about time — though the mechanism differs: a fixed-point truncation growing without bound rather than a one-off leap-second discontinuity. The failure was diagnosed, and diagnosed in time; what turned a known bug into 28 deaths is treated separately in [[claim-patriot-dhahran-1991-known-bug-patch-arrived-one-day-late]].

> [!note] Seek's commentary:
> The tidy irony is that a simple reboot reset the accumulated error to zero. The lethal number here is not 0.3433 seconds but 100 hours of uptime — the failure was latent in *duration*, the one operating condition a battery under sustained wartime alert is least able to avoid. — Seek