GPS Time vs. UTC vs. Unix Time

It's easy to assume "time" is one universal thing that every system agrees on. In practice, several different standards represent time slightly differently, for genuinely good engineering reasons, and the gaps between them are precise, documented, and growing (in one case) by design.

UTC: the human-facing standard

Coordinated Universal Time is the basis for civil timekeeping worldwide — it's what timezones are offset from, and it includes leap seconds to stay aligned with the Earth's actual, slightly irregular rotation. UTC is designed for humans and calendars, which means it occasionally has to bend to accommodate an imperfect physical world.

Unix time: seconds since 1970, no leap seconds

Unix time counts seconds since January 1, 1970, and in its most common implementation, it does not actually account for leap seconds cleanly — most systems either repeat a second or apply a smear, rather than genuinely counting 86,401 seconds on a leap-second day. This means Unix time is an approximation of elapsed real time, not a perfectly precise count of physical seconds since the epoch — close enough for virtually everything, but worth knowing if you're doing scientific-grade timing.

GPS time: no leap seconds at all

GPS time counts seconds since January 6, 1980, and by design, it never incorporates leap seconds — it just keeps counting in perfectly regular one-second increments, forever. That means GPS time and UTC drift apart by exactly one second every time a leap second is added to UTC. As of the last leap second (December 31, 2016), that gap stands at 18 seconds, and it will only grow if more leap seconds are added in the future. GPS receivers handle this by broadcasting the current UTC offset alongside the raw GPS time, so devices can convert accurately.

Why the difference actually matters

For most everyday software, Unix time is close enough and nobody needs to think about the leap-second gap at all. It matters in specific domains: satellite navigation, precise scientific timing, and any system that has to reconcile timestamps from GPS-based hardware (like vehicle telemetry or drones) against a UTC-based backend. Getting that 18-second gap wrong in the wrong context is exactly the kind of bug that's invisible until it isn't.

If you need to convert a GPS timestamp into a standard date, the Historical Epoch Converter handles the GPS-to-UTC conversion (including the leap second offset) directly.