<p>This doesn't directly answer your question but it does address the discrepancy.</p>
<p>The DAT column you are using is an integer. That is a proleptic leap second, and is not correct prior to 1972. Between 1966 and 1971 the US National Bureau of Standards (NBS, now called the National Institute of Standards and Technology (NIST)) used an concept called <a href="https://nvlpubs.nist.gov/nistpubs/Legacy/MONO/nbsmonograph140.pdf" rel="nofollow noreferrer">Stepped Atomic Time</a> in which leap sub-seconds (steps of 0.2 seconds) were occasionally added or subtracted to what is now called UTC instead of the leap seconds that have been occasionally added or subtracted since 1972.</p>
<p>Prior to 1966, I believe the corrections to what is now called UTC were made on a daily basis on the NBS radio station WWV.</p>

CC BY-SA 4.0
2022-03-07T03:24:28.690Z
Wow, time scales are really an endless labyrinth! Really interesting though. I've tried to search for tables of Stepped Atomic Time corrections but could not find them (even less radio transcripts for prior to 1966). However, JPL's [EOP2 file](https://eop2-external.jpl.nasa.gov) gives TAI-UT1 on a daily basis all the way back to 1962, I guess this is the best source I've found for now for these! It indeed is giving me a much better agreement now between the ephemerides obtained inputting time in UT and in TT, still not perfect, but very close
Rafa
CC BY-SA 4.0
2022-03-07T11:28:00.470Z
@Rafa Endless labyrinth does not quite describe the situation. It's more convoluted than that.
David Hammen
CC BY-SA 4.0
2022-03-07T11:37:32.903Z
You might get even better results if you use an interpolation (linear, Lagrange, ...) of some kind to find the value at the time of interest. Also keep in mind that there is up to a 2 millisecond difference between time as ticked by JPL's $T_{\text{eph}}$ and time as ticked by an atomic clock at sea level (TAI).
David Hammen
CC BY-SA 4.0
2022-03-07T12:13:34.107Z
I was already using linear interpolation indeed, need to explore other schemes! I need to look into that additional difference between $T_{eph}$ and TAI. Since you mention the height, I guess it is due to relativistic effects?
Rafa
CC BY-SA 4.0
2022-03-07T13:41:36.297Z
@Rafa TAI is defined as time ticked by a perfect atomic clock located on the surface of the geoid, which is very close to mean sea level. JPL and other organizations that generate ephemerides use different time scales. Some use Barycentric Coordinate Time (TCB), which is time as ticked by a perfect atomic clock located well outside the solar system. Others, including  JPL, use Barycentric Dynamic Time (TDB), which is TCB scaled by a factor intended to make TDB tick, on average, at the same rate as TAI.
David Hammen
CC BY-SA 4.0
2022-03-07T13:43:14.670Z
JPL used it's own time scale ($T_\text{eph}$) until recently. TDB was redefined to match the DE405 $T_\text{eph}$. JPL is now using TDB rather than its home-brewed $T_\text{eph}$.
David Hammen
CC BY-SA 4.0
2022-03-07T13:47:27.263Z
The primary reason TAI and TDB differ by up to a couple of milliseconds is the Earth's somewhat eccentric orbit about the Sun. On average both TAI and TDB tick at the same rate, but at any one time, one will be ticking slightly faster than the other.
David Hammen
CC BY-SA 4.0
2022-03-04T11:17:34.647Z
2022-03-04T11:30:40.667Z
2022-03-04T11:30:40.667Z
David Hammen
<p>I have recently been experimenting with <a href="https://ssd.jpl.nasa.gov/horizons/app.html#/" rel="nofollow noreferrer">JPL Horizons planet ephemerides web App</a>, and found a puzzling discrepancy.</p>
<p>Horizons allows to specify the time at which the planet ephemerides should be calculated in several ways. If we just want one or a few time points, in the Time specification tab we can choose &quot;Specify a list of times&quot; mode. We can then choose as Time-form &quot;MJD (Modified Julian Day)&quot;. Then, we can choose the time-type, of which we have 3 available: Universal Time (UT), Terrestrial [Dynamic] Time (TT) and Barycentric Dynamical Time (TDB).</p>
<p>As a test case, let's work with Mars Barycenter as the target body, with Coordinate Center: Solar System Barycenter (SSB) [500@0] 3, and with the following output settings:</p>
<ul>
<li>Output quantities: 1. Position components {x,y,z} only</li>
<li>Reference frame: ICRF</li>
<li>Reference plane: x-y axes of reference frame (equatorial or equatorial-aligned, inertial)</li>
<li>Vector correction: geometric states</li>
<li>Output units: km and seconds</li>
</ul>
<p>As a first example, let us calculate the ephemeris for Mars Barycenter for MJD=51544.5 TT, which is the same as JD(Julian Day)=51544.5 + 2400000.5=2451545 . Using <a href="https://ssd.jpl.nasa.gov/tools/jdc/#/jd" rel="nofollow noreferrer">this tool from JPL</a> we can verify that this corresponds to 2000-01-01 12:00:00 TT. We get the following position:</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Component</th>
<th>Value</th>
</tr>
</thead>
<tbody>
<tr>
<td>X</td>
<td>206980433.8363662</td>
</tr>
<tr>
<td>Y</td>
<td>-186417.0131760761</td>
</tr>
<tr>
<td>Z</td>
<td>-5667227.498321475</td>
</tr>
</tbody>
</table>
</div>
<p>We can also find out the equivalent MJD in UTC, by taking into account the following:</p>
<ol>
<li>TT (TDT; to be completely precise, it seems TT was used before TDT and TDB were defined as 2 different things) differs from TAI by 32.184 seconds</li>
<li>TAI differs from UTC by the leap seconds, which started being introduced in 1972, plus an initial accumulated difference of 10 s before the introduction of the 1st leap second.</li>
</ol>
<p>From <a href="https://www.stjarnhimlen.se/comp/time.html" rel="nofollow noreferrer">this source</a> we can see that, for the year 2000, the difference between TAI and UTC was 32 seconds (i.e., 22 leap seconds plus the initial 10 seconds difference). Overall, the difference at that point between TT and UTC was of 32.184+32=64.184 seconds. So, we can calculate the corresponding MJD in UTC as follows: 51544.5 - 64.184/86400 = 51544.499257129631587 (note the division by 86400 is to convert seconds to days).</p>
<p>If we then input this target time in Horizons web App, and specify that it is a UT time, we should get the same ephemeris. And indeed, that is the case (well, there is tiny differences of less than a couple meters, but I guess we can ignore those for now; might be due to some rounding errors somewhere):</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Component</th>
<th>Value</th>
</tr>
</thead>
<tbody>
<tr>
<td>X</td>
<td>206980433.8363839</td>
</tr>
<tr>
<td>Y</td>
<td>-186417.0128144659</td>
</tr>
<tr>
<td>Z</td>
<td>-5667227.498156091</td>
</tr>
</tbody>
</table>
</div>
<p>I then tried to perform the same test for an older date, in particular, for 1969-07-19 04:48:00 TT (during the Apollo 11 mission). Using the same Time conversion tool I linked before, we can see this is JD=2440421.7 TT, which is MJD=40421.2 TT. We need to make a note here, which is that TT/TDT was not defined until 1984. Before then, we have ET (Ephemeris Time), but according to <a href="https://www.stjarnhimlen.se/comp/time.html" rel="nofollow noreferrer">this source</a> they can be regarded as a continuous time scale. In the rest of this question, I use TT always, but it technically means ET for dates before 1984. Inputting this value (and remembering to specify that it is in TT), we obtain the following ephemeris for Mars barycenter:</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Component</th>
<th>Value</th>
</tr>
</thead>
<tbody>
<tr>
<td>X</td>
<td>29480552.64364658</td>
</tr>
<tr>
<td>Y</td>
<td>-193577194.1755700</td>
</tr>
<tr>
<td>Z</td>
<td>-89579659.90450171</td>
</tr>
</tbody>
</table>
</div>
<p>Let us now calculate the equivalent UTC time. For dates before 1972, <a href="https://www.stjarnhimlen.se/comp/time.html" rel="nofollow noreferrer">this source</a> provides the difference between UT and TT (technically ET), under table named <strong>Delta-T 1620-1972</strong>. We need to go to row 1965, column +4 (because we are dealing with the year 1969) to obtain a value of +39.20. We can then calculate the equivalent UTC time as MJD= 40421.2 - 39.2/86400 = 40421.199546296295011 UTC. If we then input this value in Horizons (remembering to tell it it is an UT time), we get this for Mars barycenter:</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Component</th>
<th>Value</th>
</tr>
</thead>
<tbody>
<tr>
<td>X</td>
<td>29480566.46219511</td>
</tr>
<tr>
<td>Y</td>
<td>-193577191.3534565</td>
</tr>
<tr>
<td>Z</td>
<td>-89579658.98486346</td>
</tr>
</tbody>
</table>
</div>
<p>As we can see, the differences are of quite a few kilometers now! This might seem small, but I am currently trying to simulate the trajectory of the Apollo 11 mission. At a point during the simulation, I perform a change of the center of coordinates from Earth to Moon based on JPL ephemerides, so an error of kilometers here will lead to very wrong trajectories from that point on.</p>
<p>Interestingly, it does not happen for a date in 2000, as shown above. I have tried different other procedures (wrong in principle, but I tried just to see if Horizons was doing that internally) to convert from TT to UTC time:</p>
<ul>
<li>Using a difference between TAI and UTC of 8 seconds for 1969, leading to a difference between TT and UTC of 8+32.184=40.184 seconds. The choice of 8 seconds is based on the value given in <a href="https://celestrak.org/SpaceData/EOP-All.txt" rel="nofollow noreferrer">CelesTrak Earth Orientation Parameters aggregated file</a>.</li>
<li>Using a difference between TT and UTC of 32.184 seconds for 1969, i.e., assuming that TT and UTC were equal.</li>
</ul>
<p>None of these led to the same ephemeris as with the corresponding TT value.</p>
<p>Does anybody have any idea from where this difference in ephemerides obtained with equivalent TT and UTC for 1969 is arising? I guess internally Horizons is converting times as follows: UTC -&gt; TT -&gt; TDB, since TDB is what actually needs to be input together with Chebyshev coefficients to calculate the ephemeris. Somehow, the conversion between UTC and TT for 1969 is different than what expected, but I cannot figure out how.</p>

CC BY-SA 4.0
2022-03-04T15:31:46.677Z
Astronomer [Steve Allen](https://astronomy.stackexchange.com/users/14050/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). There's a lot of info on that site, and it's a bit of a rabbit warren, with the same info repeated in various places. It's probably a good idea to start with the brief article [Two kinds of time are necessary](https://www.ucolick.org/~sla/leapsecs/twokindsoftime.html).
PM 2Ring
CC BY-SA 4.0
2022-03-04T15:32:31.403Z
For your specific question, this table may be useful: https://hpiers.obspm.fr/iers/bul/bulc/TimeSteps.history
PM 2Ring
CC BY-SA 4.0
2022-03-04T15:38:58.703Z
BTW, the IETF maintains a machine-readable leap-seconds list. https://www.ietf.org/timezones/data/leap-seconds.list You can fetch & parse it in Python like this: https://gist.github.com/PM2Ring/9dc0fa6a39dafb88b9e30f514b0dfead
PM 2Ring
CC BY-SA 4.0
2022-03-04T18:31:49.110Z
For this problem this [offset table](https://cdf.gsfc.nasa.gov/html/CDFLeapSeconds.txt) between TAI and 'UTC" is better since it extends before 1972 when UTC was formally established
astrosnapper
CC BY-SA 4.0
2022-03-04T21:51:13.383Z
The Horizons manual details how they use Delta-T.  Make sure you're using what they're using:
https://ssd.jpl.nasa.gov/horizons/manual.html
Greg Miller
CC BY-SA 4.0
2022-03-07T03:26:00.387Z
Following the link provided by @GregMiller I arrived to the [EOP2 file](https://eop2-external.jpl.nasa.gov). Using the TAI-UT1 value given there seems to make the 2 ephemerides be much closer!
Rafa
<orbital-mechanics><time><ephemeris>
Discrepancy in Horizons planet ephemerides for equivalent times in TT and UTC in dates during 1969
Rafa
# Discrepancy in Horizons planet ephemerides for equivalent times in TT and UTC in dates during 1969

(Asked by: username_0 on 2022-03-04)

I have recently been experimenting with [JPL Horizons planet ephemerides web App](https://ssd.jpl.nasa.gov/horizons/app.html#/), and found a puzzling discrepancy.

Horizons allows to specify the time at which the planet ephemerides should be calculated in several ways. If we just want one or a few time points, in the Time specification tab we can choose "Specify a list of times" mode. We can then choose as Time-form "MJD (Modified Julian Day)". Then, we can choose the time-type, of which we have 3 available: Universal Time (UT), Terrestrial [Dynamic] Time (TT) and Barycentric Dynamical Time (TDB).

As a test case, let's work with Mars Barycenter as the target body, with Coordinate Center: Solar System Barycenter (SSB) [500@0] 3, and with the following output settings:

* Output quantities: 1. Position components {x,y,z} only
* Reference frame: ICRF
* Reference plane: x-y axes of reference frame (equatorial or equatorial-aligned, inertial)
* Vector correction: geometric states
* Output units: km and seconds

As a first example, let us calculate the ephemeris for Mars Barycenter for MJD=51544.5 TT, which is the same as JD(Julian Day)=51544.5 + 2400000.5=2451545 . Using [this tool from JPL](https://ssd.jpl.nasa.gov/tools/jdc/#/jd) we can verify that this corresponds to 2000-01-01 12:00:00 TT. We get the following position:

| Component | Value |
| --- | --- |
| X | 206980433.8363662 |
| Y | -186417.0131760761 |
| Z | -5667227.498321475 |

We can also find out the equivalent MJD in UTC, by taking into account the following:

1. TT (TDT; to be completely precise, it seems TT was used before TDT and TDB were defined as 2 different things) differs from TAI by 32.184 seconds
2. TAI differs from UTC by the leap seconds, which started being introduced in 1972, plus an initial accumulated difference of 10 s before the introduction of the 1st leap second.

From [this source](https://www.stjarnhimlen.se/comp/time.html) we can see that, for the year 2000, the difference between TAI and UTC was 32 seconds (i.e., 22 leap seconds plus the initial 10 seconds difference). Overall, the difference at that point between TT and UTC was of 32.184+32=64.184 seconds. So, we can calculate the corresponding MJD in UTC as follows: 51544.5 - 64.184/86400 = 51544.499257129631587 (note the division by 86400 is to convert seconds to days).

If we then input this target time in Horizons web App, and specify that it is a UT time, we should get the same ephemeris. And indeed, that is the case (well, there is tiny differences of less than a couple meters, but I guess we can ignore those for now; might be due to some rounding errors somewhere):

| Component | Value |
| --- | --- |
| X | 206980433.8363839 |
| Y | -186417.0128144659 |
| Z | -5667227.498156091 |

I then tried to perform the same test for an older date, in particular, for 1969-07-19 04:48:00 TT (during the Apollo 11 mission). Using the same Time conversion tool I linked before, we can see this is JD=2440421.7 TT, which is MJD=40421.2 TT. We need to make a note here, which is that TT/TDT was not defined until 1984. Before then, we have ET (Ephemeris Time), but according to [this source](https://www.stjarnhimlen.se/comp/time.html) they can be regarded as a continuous time scale. In the rest of this question, I use TT always, but it technically means ET for dates before 1984. Inputting this value (and remembering to specify that it is in TT), we obtain the following ephemeris for Mars barycenter:

| Component | Value |
| --- | --- |
| X | 29480552.64364658 |
| Y | -193577194.1755700 |
| Z | -89579659.90450171 |

Let us now calculate the equivalent UTC time. For dates before 1972, [this source](https://www.stjarnhimlen.se/comp/time.html) provides the difference between UT and TT (technically ET), under table named **Delta-T 1620-1972**. We need to go to row 1965, column +4 (because we are dealing with the year 1969) to obtain a value of +39.20. We can then calculate the equivalent UTC time as MJD= 40421.2 - 39.2/86400 = 40421.199546296295011 UTC. If we then input this value in Horizons (remembering to tell it it is an UT time), we get this for Mars barycenter:

| Component | Value |
| --- | --- |
| X | 29480566.46219511 |
| Y | -193577191.3534565 |
| Z | -89579658.98486346 |

As we can see, the differences are of quite a few kilometers now! This might seem small, but I am currently trying to simulate the trajectory of the Apollo 11 mission. At a point during the simulation, I perform a change of the center of coordinates from Earth to Moon based on JPL ephemerides, so an error of kilometers here will lead to very wrong trajectories from that point on.

Interestingly, it does not happen for a date in 2000, as shown above. I have tried different other procedures (wrong in principle, but I tried just to see if Horizons was doing that internally) to convert from TT to UTC time:

* Using a difference between TAI and UTC of 8 seconds for 1969, leading to a difference between TT and UTC of 8+32.184=40.184 seconds. The choice of 8 seconds is based on the value given in [CelesTrak Earth Orientation Parameters aggregated file](https://celestrak.org/SpaceData/EOP-All.txt).
* Using a difference between TT and UTC of 32.184 seconds for 1969, i.e., assuming that TT and UTC were equal.

None of these led to the same ephemeris as with the corresponding TT value.

Does anybody have any idea from where this difference in ephemerides obtained with equivalent TT and UTC for 1969 is arising? I guess internally Horizons is converting times as follows: UTC -> TT -> TDB, since TDB is what actually needs to be input together with Chebyshev coefficients to calculate the ephemeris. Somehow, the conversion between UTC and TT for 1969 is different than what expected, but I cannot figure out how.

**Tags:** orbital-mechanics, time, ephemeris

> **Comments:**
> **username_1**: Astronomer [Steve Allen](https://astronomy.stackexchange.com/users/14050/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). There's a lot of info on that site, and it's a bit of a rabbit warren, with the same info repeated in various places. It's probably a good idea to start with the brief article [Two kinds of time are necessary](https://www.ucolick.org/~sla/leapsecs/twokindsoftime.html).  
> **username_1**: For your specific question, this table may be useful: https://hpiers.obspm.fr/iers/bul/bulc/TimeSteps.history  
> **username_1**: BTW, the IETF maintains a machine-readable leap-seconds list. https://www.ietf.org/timezones/data/leap-seconds.list You can fetch & parse it in Python like this: https://gist.github.com/username_1/9dc0fa6a39dafb88b9e30f514b0dfead  
> **username_2**: For this problem this [offset table](https://cdf.gsfc.nasa.gov/html/CDFLeapSeconds.txt) between TAI and 'UTC" is better since it extends before 1972 when UTC was formally established  
> **username_3**: The Horizons manual details how they use Delta-T.  Make sure you're using what they're using: https://ssd.jpl.nasa.gov/horizons/manual.html  
> **username_0**: Following the link provided by @username_3 I arrived to the [EOP2 file](https://eop2-external.jpl.nasa.gov). Using the TAI-UT1 value given there seems to make the 2 ephemerides be much closer!  

---

## 1 answers

### Answer by username_4 on 2022-03-04. Score: 4 | Accepted answer

This doesn't directly answer your question but it does address the discrepancy.

The DAT column you are using is an integer. That is a proleptic leap second, and is not correct prior to 1972. Between 1966 and 1971 the US National Bureau of Standards (NBS, now called the National Institute of Standards and Technology (NIST)) used an concept called [Stepped Atomic Time](https://nvlpubs.nist.gov/nistpubs/Legacy/MONO/nbsmonograph140.pdf) in which leap sub-seconds (steps of 0.2 seconds) were occasionally added or subtracted to what is now called UTC instead of the leap seconds that have been occasionally added or subtracted since 1972.

Prior to 1966, I believe the corrections to what is now called UTC were made on a daily basis on the NBS radio station WWV.

> **Comments:**
> **username_0**: Wow, time scales are really an endless labyrinth! Really interesting though. I've tried to search for tables of Stepped Atomic Time corrections but could not find them (even less radio transcripts for prior to 1966). However, JPL's [EOP2 file](https://eop2-external.jpl.nasa.gov) gives TAI-UT1 on a daily basis all the way back to 1962, I guess this is the best source I've found for now for these! It indeed is giving me a much better agreement now between the ephemerides obtained inputting time in UT and in TT, still not perfect, but very close  
> **username_4**: @username_0 Endless labyrinth does not quite describe the situation. It's more convoluted than that.  
> **username_4**: You might get even better results if you use an interpolation (linear, Lagrange, ...) of some kind to find the value at the time of interest. Also keep in mind that there is up to a 2 millisecond difference between time as ticked by JPL's $T_{\text{eph}}$ and time as ticked by an atomic clock at sea level (TAI).  
> **username_0**: I was already using linear interpolation indeed, need to explore other schemes! I need to look into that additional difference between $T_{eph}$ and TAI. Since you mention the height, I guess it is due to relativistic effects?  
> **username_4**: @username_0 TAI is defined as time ticked by a perfect atomic clock located on the surface of the geoid, which is very close to mean sea level. JPL and other organizations that generate ephemerides use different time scales. Some use Barycentric Coordinate Time (TCB), which is time as ticked by a perfect atomic clock located well outside the solar system. Others, including  JPL, use Barycentric Dynamic Time (TDB), which is TCB scaled by a factor intended to make TDB tick, on average, at the same rate as TAI.  
> **username_4**: JPL used it's own time scale ($T_\text{eph}$) until recently. TDB was redefined to match the DE405 $T_\text{eph}$. JPL is now using TDB rather than its home-brewed $T_\text{eph}$.  
> **username_4**: The primary reason TAI and TDB differ by up to a couple of milliseconds is the Earth's somewhat eccentric orbit about the Sun. On average both TAI and TDB tick at the same rate, but at any one time, one will be ticking slightly faster than the other.  

---

