I've written a high fidelity time management library (hifitime, currently in Rust, Python interface planned) which converts between time systems (TT, TAI, UTC, etc.) and time representations (Gregorian, JDE, MJD).

The current TDB computation uses ESA's Navipedia documentation. I found something similar in SPICE's documentation, but I have a hard time figuring out how to use that to convert between a TT epoch and a TDB epoch: from my validation examples, there's a very small difference between ESA and NASA's computation.

Could someone provide me an example of the execution of the SPICE algorithm if I have a TT epoch in seconds past J2000 and would like SPICE's TDB?


2 Answers 2


Neither one is correct. The two use slightly different approximations. SPICE's documentation, which you have found, uses $$TDB - TDT = K * sin (E)$$ where "$K$ is a constant and $E$ is the eccentric anomaly of the heliocentric orbit of the Earth-Moon barycenter". SPICE approximates the eccentric anomaly via $$E = M + e \sin (M)$$. This is incorrect. The correct expression is Kepler's equation, $$M = E - e\sin E$$. Inverting this to compute $E$ from $M$ (the mean anomaly) is the Kepler problem. The expression used by JPL is approximately correct for nearly circular orbits.

Navipedia uses a slightly different approximation, but it too is an approximation. It uses slightly different constants. Both approximations assume that TDB and TDT differ based on the distance and velocity between the Earth and the Sun, and that the Earth's orbit can be modeled as Keplerian. TDB and TDT instead differ based on the distance and velocity between the Earth and the solar system barycenter. Moreover, the Earth's orbit about the Sun is not quite Keplerian.


If you want high fidelity, you need to consult a more detailed reference, such as the International Astronomical Union's Standards Of Fundamental Astronomy. The SOFA Time Scale and Calendar Tools most recent revision is dated June 2020, and says, for example:

Of the seven time scales to be described here, one is atomic time (TAI), one is solar time (UT1), one is an atomic/solar hybrid (UTC) and four are dynamical times (TT, TCG, TCB, TDB). Each has a distinct role, and there are offsets of tens of seconds between some of them: when planning an astronomical calculation it is vital to choose the right one. A particularly common mistake is to assume that there is just one sort of precise time, namely UTC, compatible with everything from telescope pointing (which actually requires UT1) to looking up planetary positions (which requires TDB, which may be approximated by TT).

In fact, don't write the conversion equations yourself! Download the free C code for SOFA from https://www.iausofa.org/current.html , and just write a wrapper around it for your other languages.

  • $\begingroup$ Thanks! I didn't know that SOFA had time management as well (makes sense though). Also thanks for linking to the license: I'll read it thoroughly and probably adapt some of the SOFA algorithms into hifitime. I tend to avoid using C wrappers after a long yet fruitless attempt of wrapping CSPICE in Rust: rust is thread safe by design, SPICE is not, and that led to really bad race conditions. From this sparked hifitime and the ephemeris interpretation format in Nyx. $\endgroup$
    – ChrisR
    Dec 25, 2020 at 19:18
  • $\begingroup$ @ChrisR My pleasure. Thank you for mentioning Nyx -- now I have another tool to investigate. How exactly is it validated? Last time I tried to use GMAT, its variable-step integrator was so broken it made me abandon the whole thing. I would take this offline, but I haven't figured out how to message just you directly... $\endgroup$
    – Ryan C
    Dec 26, 2020 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.