<p>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.</p>
<p>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.</p>
<p>GPS time is very close to being exactly 19 seconds behind International Atomic Time (TAI). &quot;Very close&quot; 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.</p>
<p>Ignoring that detail, its best to look at GPS time as always being exactly 19 seconds behind TAI. Neither time scale has leap seconds.</p>

CC BY-SA 4.0
2023-02-19T16:40:20.077Z
2023-02-19T16:40:20.077Z
David Hammen
<p>You are correct, and the website is wrong.</p>
<p>GPS time is co-moving with TAI, so the simplest way is to calculate everything in TAI:</p>
<p>J2000.0(0) = 2000-01-01 11:59:27.816 TAI<br>
GPST(0) = 1980-01-06 00:00:19 TAI</p>
<p>J2000.0(0) - GPST(0) = 7300 days 11:59:08.816 TAI</p>
<p>7300 days = 1042 weeks + 6 days</p>
<p>11:59:08.816 = 43148.816 seconds</p>
<p>6 days + 43148.816 seconds = 561548.816 seconds</p>
<p>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).</p>
<p>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.</p>

CC BY-SA 4.0
2023-02-17T21:03:21.333Z
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)
astrosnapper
CC BY-SA 4.0
2023-02-17T14:50:19.227Z
2023-02-17T14:50:19.227Z
Teemu Kalvas
<p>The simple version of the question is: <strong>what was the GPS time expressed in week number (pure number) and time of week (SI seconds) at the J2000 epoch?</strong> I am asking because my hand calculations differ from what I get from the <a href="https://gnsscalc.com/" rel="nofollow noreferrer">https://gnsscalc.com/</a> website.</p>
<p><em>Long version (no need to read it all, if you are not interested in the details).</em></p>
<p>We know that <a href="https://en.wikipedia.org/wiki/Equinox_(celestial_coordinates)#J2000.0" rel="nofollow noreferrer">J2000.0</a> 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 <a href="https://gssc.esa.int/navipedia/index.php/Time_References_in_GNSS" rel="nofollow noreferrer">GPS time</a> 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 <a href="https://gssc.esa.int/navipedia/index.php/Transformations_between_Time_Systems#GNSS_.E2.80.93_TAI" rel="nofollow noreferrer">not affected</a> by leap seconds and they all share the same definition of a SI second, that is the <a href="https://en.wikipedia.org/wiki/International_Atomic_Time" rel="nofollow noreferrer">Cesium standard</a>.</p>
<p>So it should be straightforward to obtain the GPS time at J2000 epoch by the following calculation:</p>
<pre><code>GPS time origin -&gt; 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 -&gt; Saturday 1 Jan 2000 11:59:08.816 GPST - 11:59:27.816 TAI - 12:00:00 TT
</code></pre>
<p>In total, I get that the GPS time at J2000.0 epoch (<code>GPS time at J2000 epoch - GPS time origin</code>) 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.</p>

CC BY-SA 4.0
2023-02-19T19:03:16.017Z
Astronomer Steve Allen maintains an extensive website on [leap seconds](https://www.ucolick.org/~sla/leapsecs/) and related matters, eg the history of [time scales](https://www.ucolick.org/~sla/leapsecs/timescales.html). Also see http://leapsecond.com/
PM 2Ring
<time><artificial-satellite>
What was the GPS time at J2000 epoch?
LastStarDust
# What was the GPS time at J2000 epoch?

(Asked by: username_0 on 2023-02-17)

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.

**Tags:** time, artificial-satellite
> **Comments:**
> **username_1**: Astronomer Steve Allen maintains an extensive website on [leap seconds](https://www.ucolick.org/~sla/leapsecs/) and related matters, eg the history of [time scales](https://www.ucolick.org/~sla/leapsecs/timescales.html). Also see http://leapsecond.com/  

---

## 2 answers

### Answer by username_3 on 2023-02-17. Score: 6 | Accepted answer

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.

> **Comments:**
> **username_4**: 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)  

---

### Answer by username_2 on 2023-02-19. Score: 2

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.


---

