GPS / TAI Time

This converter relates three time scales that GNSS logs mix constantly: UTC expressed as Unix seconds, International Atomic Time (TAI), and GPS time as week number plus seconds of week. GPS time began at 00:00 UTC on 6 January 1980 and does not insert leap seconds. TAI counts SI seconds continuously. POSIX Unix time labels 86,400 seconds on each civil day and omits leap seconds from the count. Use this page for receiver week-rollover notes and lab stamps—not for a navigation solution, and not for NTP packet fields.

GPS week, TOW, and the 1980 epoch

GPS week is the integer number of 604,800-second weeks since the GPS epoch. Seconds of week (TOW) run from 0 through 604,799. Paste week and TOW as 2345,345678 or 2345 345678. Prefixes gps:, tai:, and unix: disambiguate a bare integer, which otherwise could be any of the three second counts. A calendar date converts UTC midnight into the same family of fields.

GPS time equals TAI minus 19 seconds by definition. At the GPS epoch, TAI−UTC was 19 seconds, so GPS and UTC agreed. UTC later inserted leap seconds; GPS did not. The GPS-minus-UTC difference is therefore the count of those leaps since 1980. The converter applies the published IERS leap-second table; it does not predict a future leap.

Aircraft and survey logs sometimes mix GPS week with “UTC of week.” If TOW looks like a millisecond field (values far above 604,800), you do not have seconds-of-week. Stop and check the ICD for that receiver before converting. Some receivers publish TOW in milliseconds of week (values up to about 604,800,000); dividing by 1,000 recovers seconds of week. Pasting that millisecond field as TOW seconds will look like many weeks piled into one field and will not match the lab Unix clock.

Ten-bit weeks without a rollover calendar

Many receivers store only ten bits of the week counter. That field wraps every 1,024 weeks—a little under twenty years. A decoded date that looks about two decades off often needs 1,024 added to the 10-bit week. This page prints both the full week and the 10-bit remainder so a log that says “week 200” can be placed in the correct era from context, not from a memorized list of rollover civil dates.

Firmware that has not implemented the latest wrap will jump backward 1,024 weeks. Inventory scripts for 2026 should record whether the week in a file is full or 10-bit. Adding 1,024 and converting again is the usual lab check; guessing a civil year from folklore is not.

Leap seconds, TAI, and what JavaScript can show

JavaScript Date follows POSIX and cannot represent 23:59:60. Conversions here are therefore second-accurate for civil UTC days, not a full ITU leap-second smear. The offset table is the published TAI−UTC steps. Recalculate after a leap second if one is ever announced again. Mixing GPS seconds with Unix seconds is a common off-by-the-leap-count incident in distributed traces; name the scale in the ticket.

A backend that stores TAI-like counters (Unix plus the current TAI−UTC offset) can prefix tai: and confirm the civil date. Do not treat that integer as Unix in a dashboard or the plot will sit that many seconds in the future. Classroom labs in 2026 can convert “now” on the Unix page, then convert the same civil date here to see the GPS offset without claiming the receiver’s PVT is wrong by that many seconds.

This is not a PVT engine: no satellite ephemeris, no ionosphere, no city wall clock besides UTC. For city wall times use a time zone converter after you have UTC.

Not NTP, and not a 32-bit POSIX clock

NTP era 0 is a 32-bit seconds field counted from 1 January 1900. It wraps after about 136 years. That wrap is a protocol-clock problem with a different epoch and period than GPS week. Convert packet dumps on NTP timestamp. Do not prefix gps: there, and do not paste NTP hex into week+TOW here.

Signed 32-bit Unix overflow is a storage problem for POSIX seconds, not a GPS-week problem. When the constraint is a 32-bit time_t, open the 32-bit overflow converter rather than this GNSS page. Everyday second decoding without week or TAI still belongs on Unix timestamp.

Document which scale a file uses. Share dates as ISO-8601 UTC in email; let each team convert to GPS or TAI locally so nobody pastes an unlabeled integer. Keep the converters hub nearby when the next integer might be FILETIME, NTP, or Unix after all.

RINEX lines and lab alignment

A test engineer who copies a RINEX TOW and week from a GNSS log can paste week,TOW, read UTC, and file the ISO stamp next to the lab’s Unix clock so the two systems can be aligned in a bug report. If the week field is 10-bit, print both values from this page into the ticket so the next shift does not pick the wrong era.

Start from a UTC date when you only have a civil day and no receiver fields. The result lists ISO-8601 UTC, Unix seconds, TAI−UTC, GPS−UTC, TAI seconds, GPS seconds since 1980, week, 10-bit week, and TOW. Name the scale in the ticket: UTC, TAI, or GPS week+TOW. Record whether the week is full or 10-bit before anyone diffs two log files from 2026.