Confusion about Julian Date

[karatemir]

Hi there,

I am trying to do some LTAN calculations for a SSO orbit satellite and while comparing against beyond and orbit-predictor I came across some discrepancies. Following script depicts the difference:

from skyfield.api import EarthSatellite, load, utc
from orbit_predictor.utils import juliandate, timetuple_from_dt
from beyond.io.tle import Tle
from beyond.utils.ltan import _sideral

ts = load.timescale()

bee = """\
1 48884U 21059F   22271.35224498  .00012911  00000+0  65126-3 0  9996
2 48884  97.5684  40.5481 0009089 109.4705 250.7511 15.17231497 69520
"""

sat = EarthSatellite(*bee.splitlines())
orb = Tle(bee).orbit()

print(f"{sat.epoch.tt}, {sat.epoch.utc_datetime()}")
print(f"{orb.date.jd}, {orb.date.datetime}")
print(f"{juliandate(timetuple_from_dt(orb.date.datetime))}")

which returns:

2459850.8530457206, 2022-09-28 08:27:13.966278+00:00
2459850.85224498, 2022-09-28 08:27:13.966272
2459850.85224498

As can be seen sat.epoch.tt is different from what beyond and orbit-predictor returns. However, I can get the same value (2459850.85224498) with

sat.model.jdsatepoch + sat.model.jdsatepochF

Can someone explain why epoch's tt (Terrestrial Time (TT) as a Julian date.) is different in Skyfield compared to beyond. How does tt vs sat.model.jdsatepoch + sat.model.jdsatepochF differ?

Similarly, to do LTAN computations beyond computes GMST here, there is some difference here too:

print(f"{_sideral(orb.date)}")
print(f"{ (sat.epoch.gmst * 3600 / 240) % 360}")
### returns
### 133.9102213238366
### 133.9100957958627

Thanks a lot in advance!

[brandon-rhodes]

Epochs are expressed in UTC, not TT. You can learn more about the different timescales that Skyfield supports here, which will hopefully answer your questions:

https://rhodesmill.org/skyfield/time.html#uniform-time-scales-tai-tt-and-tdb

[karatemir]

@brandon-rhodes thanks for the link. Reading that I understand the need for different nuances but I guess my confusion is more fundamental. Following script I believe explains my problem the best:

from skyfield.api import EarthSatellite, load
from skyfield.timelib import julian_date

ts = load.timescale()

bee = """\
1 48884U 21059F   22271.35224498  .00012911  00000+0  65126-3 0  9996
2 48884  97.5684  40.5481 0009089 109.4705 250.7511 15.17231497 69520
"""
sat = EarthSatellite(*bee.splitlines(), ts=ts)

print(f"""
Julian Date from model: {sat.model.jdsatepoch + sat.model.jdsatepochF}, 
from func: {julian_date(*sat.epoch.utc)}
""")

which prints

Julian Date from model: 2459850.85224498, 
from func: 2459850.85224498

So basically we can recover the jdsatepoch SGP4 uses from Skyfield epoch. However epoch itself is <Time tt=2459850.8530457206>. Why does Skyfield return an epoch different from what Satrec uses. For instance according to this issue if I would like to create an exact replica of a satellite that was created from a TLE I would need to use jdsatepoch within Satrec sgp4init.

Is there a specific use for sat.epoch.tt? If there is, then when and where should one use TT vs JD? Documentation also makes it more confusing, here: t.tt is defined as "Terrestrial Time (TT) as a Julian date."

Another question: above script shows a way to go from tt to jd. What can I do for the opposite: jd --> tt?

[psbaltar]

Another question: above script shows a way to go from tt to jd. What can I do for the opposite: jd --> tt?

I believe that this is where the confusion lies. A Julian date is a way to represent a time whereas TT and UTC are time scales. So TT can be represented as a Julian date; it's not converted.

A Julian date is the number of days since some specific time in the past. So 2022-10-14 14:36 UTC can be represented as a Julian date by counting the number of days (and fraction of a day) between then and the start of the Julian calendar.

TT and UTC are two of several time scales used in modern astronomy. They each measure time in different ways for different purposes. In particular, TT ticks at a constant rate but UTC does not. UTC gets occasional adjustments so that a "day" is tied to Earth's rotation, which varies slightly. Every so often, there's a UTC day that's 1s longer than normal (a leap second). I believe that TT is currently ~67s ahead of UTC.

Imagine having 2 clocks on the wall that tick at different rates. Either (or both) can be used to mark the same instant even though they have different readings. So t.tt is that instant in TT while t.utc is that same instant in UTC.