The simple version of the question is: what was the GPS time expressed in week number (pure number) and time of week (SI seconds) at the J2000 epoch? I am asking because my hand calculations differ from what I get from the https://gnsscalc.com/ website.

Long version (no need to read it all, if you are not interested in the details).

We know that J2000.0 is defined as Julian Date 2451545.0 TT, which is equal to 2000-01-01 12:00:00 TT, which is equal to 2000-01-01 11:59:27.816 TAI. The GPS time is calculated as weeks (pure number) and time of week (SI seconds) elapsed since 1980-01-06 00:00:00 UTC. Moreover GPS time, TAI and TT are not affected by leap seconds and they all share the same definition of a SI second, that is the Cesium standard.

So it should be straightforward to obtain the GPS time at J2000 epoch by the following calculation:

GPS time origin -> Sunday 06 Jan 1980 00:00:00 GPST - 00:00:19 TAI - 00:00:51.184 TT

+ 1042 weeks

Sunday 26 Dec 1999 00:00:00 GPST - 00:00:19 TAI - 00:00:51.184 TT

+ 6 days + 11 hours + 59 minutes + 08 seconds + 816 milliseconds = 561548.816 seconds

J2000 epoch -> Saturday 1 Jan 2000 11:59:08.816 GPST - 11:59:27.816 TAI - 12:00:00 TT

In total, I get that the GPS time at J2000.0 epoch (GPS time at J2000 epoch - GPS time origin) is 1042 weeks and 561548.816 seconds that is different from the value of 1042 weeks and 561535.816 seconds I get from the website. In the website notes, it is written that the leap second is taken into account for TAI and TT calculations but I do not understand how.


2 Answers 2


You are correct, and the website is wrong.

GPS time is co-moving with TAI, so the simplest way is to calculate everything in TAI:

J2000.0(0) = 2000-01-01 11:59:27.816 TAI
GPST(0) = 1980-01-06 00:00:19 TAI

J2000.0(0) - GPST(0) = 7300 days 11:59:08.816 TAI

7300 days = 1042 weeks + 6 days

11:59:08.816 = 43148.816 seconds

6 days + 43148.816 seconds = 561548.816 seconds

Now, I didn't go into the website source to try to figure out which way it performs all these calculations, but the effect seems to be as if it made a leap second correction, which isn't supposed to be there. If you convert from 1981-07-01 00:00:00 UTC you get GPS time-of-week 259200 (which is one too little) and if you convert from 1981-06-30 23:59:59 UTC you get 259199 (which is correct).

I tried another free converter on the web by googling and selecting one at random, and it seemed to agree with me. Sometimes even good looking design and an official looking url doesn't mean a free service is worth the price you paid.

  • 2
    $\begingroup$ Astropy's Time module, which has transparent means of handling the offsets between time systems behind the scenes, confirms this number (for what this is worth) $\endgroup$ Commented Feb 17, 2023 at 21:03

Your result, which is correct, differs from the cited website's result by 13 seconds -- that is the number of leap seconds introduced between the GPS epoch time and the J2000 epoch time. The website is wrong.

The number of leap seconds that have been introduced since the GPS epoch time is part of the 12.5 minute long GPS navigation message, but it is distinct from the GPS time. The rollover from one GPS week number to the next is always separated by 7*86400=604800 SI seconds; no leap seconds are involved.

GPS time is very close to being exactly 19 seconds behind International Atomic Time (TAI). "Very close" used to mean being within a few tens of nanoseconds of being exactly 19 seconds behind TAI. For the last two years, GPS time has been within a just few nanoseconds of being exactly 19 seconds behind TAI. The issue is that GPS time is based on atomic clocks managed by the US Naval Observatory, but not all the other atomic clocks around the world go into TAI. TAI is a several hours after the fact time scale.

Ignoring that detail, its best to look at GPS time as always being exactly 19 seconds behind TAI. Neither time scale has leap seconds.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .