5
$\begingroup$

I have recently been experimenting with JPL Horizons planet ephemerides web App, 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 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 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 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 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.
  • 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.

$\endgroup$
6

1 Answer 1

4
$\begingroup$

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 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.

$\endgroup$
7
  • 2
    $\begingroup$ @Rafa Endless labyrinth does not quite describe the situation. It's more convoluted than that. $\endgroup$ Commented Mar 7, 2022 at 11:28
  • 1
    $\begingroup$ 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). $\endgroup$ Commented Mar 7, 2022 at 11:37
  • 1
    $\begingroup$ @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. $\endgroup$ Commented Mar 7, 2022 at 13:41
  • 1
    $\begingroup$ 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}$. $\endgroup$ Commented Mar 7, 2022 at 13:43
  • 2
    $\begingroup$ 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. $\endgroup$ Commented Mar 7, 2022 at 13:47

You must log in to answer this question.

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