Skip to main content
Technology

The GPS Time System - How Satellites Use Precise Time to Find You

Positioning by Time - Why Nanoseconds Matter

GPS works by measuring tiny differences in the arrival times of radio signals from multiple satellites and triangulating the receiver's position. Radio waves travel at the speed of light (about 300,000 km/s), so a 1-nanosecond timing error translates directly into about 30 cm of position error. Civilian GPS accurate to a few meters implies time synchronization at the few-tens-of-nanoseconds level.

Positioning requires signals from at least four satellites. Three fix the three-dimensional position (latitude, longitude, altitude); the fourth corrects the receiver's clock error. Receivers contain inexpensive quartz oscillators that drift microseconds from the satellite atomic clocks, but the fourth signal lets the system solve for that offset. Without this trick, every GPS receiver would need an expensive on-board atomic clock.

Satellite Atomic Clocks - Rubidium and Cesium

Modern GPS satellites (Block IIF and later) carry three rubidium and one cesium atomic clock each. Rubidium clocks are smaller, lighter, lower-power, and have excellent short-term stability. Cesium clocks have superior long-term stability but are larger and more power-hungry, so the cesium unit serves as a backup.

Ground control stations regularly correct each satellite's clock. Worldwide monitor stations measure the satellite's clock error precisely, and corrections are uploaded to the satellites and broadcast in the navigation message. Receivers apply these corrections during position calculation, so the system tolerates small per-satellite drifts without compromising user accuracy.

Relativistic Corrections - 38 Microseconds Per Day

GPS is one of the few systems that must explicitly account for both general and special relativity in its operations. General relativity predicts that clocks tick faster where gravity is weaker. At the GPS satellite altitude of about 20,000 km, the gravitational potential is higher than on the ground, making satellite clocks run about 45.8 microseconds per day faster than ground clocks.

Special relativity, in turn, predicts that fast-moving clocks tick more slowly. GPS satellites orbit at about 3.87 km/s, which slows their clocks by about 7.2 microseconds per day. The two effects combine to make satellite clocks net 38.6 microseconds per day faster than ground clocks. Without this correction, GPS position errors would accumulate at about 11.6 km per day, rendering the system unusable within hours. The fact that GPS works at all is a daily, practical confirmation of Einstein's predictions.

GPS Time vs UTC - A Continuous Time Scale

GPS time (GPST) starts at 00:00:00 UTC on January 6, 1980 and runs continuously without leap seconds. As leap seconds have been inserted into UTC over the decades, GPST has accumulated an offset ahead of UTC. As of 2026, GPST leads UTC by 18 seconds. (At GPS epoch in 1980, TAI led UTC by 19 seconds, and GPST was defined as TAI minus 19 seconds.)

GPS receivers use UTC offset information from the navigation message to convert GPST to UTC. This offset updates each time a leap second is inserted. After 2035 abolition, the GPST-UTC offset will become permanent, and the conversion reduces to a fixed constant subtraction, simplifying receiver firmware and operational maintenance.

Week Number Rollover - The 1024-Week Wall

The GPS navigation message represents dates as a week number plus seconds within that week. Original GPS allocated 10 bits to the week number, rolling over after 1024 weeks (about 19.7 years). The first rollover happened on August 21, 1999, and some older receivers reported dates back in 1980 due to firmware bugs. The second rollover occurred on April 6, 2019.

Modern GPS signals (L2C, L5) extend the week number to 13 bits, supporting 8192 weeks (about 157 years). However, older receivers and embedded systems may still use firmware that treats the week number as 10 bits. The next 10-bit rollover is in November 2038, coinciding closely with the Unix 2038 problem and likely requiring coordinated remediation across many embedded systems.

XB!LINE

Was this article helpful?

Related Articles