How to obtain UTC of the epoch time in a satellite TLE (two line element)?

I want to convert the epoch time of a TLE to UTC. At this moment I am less interested in explanations and history - I just want to know quantitatively, with certainty, how to convert.

I'm confused because I see references to both UT and JD in NASA and Celestrak sites as show below. Since Julian Date currently leads UT by approximately 68.184 seconds (as well as a 0.5D offset), I am stuck.

The epoch time in the TLE is used in at least two ways. First - it's the time when the prediction from the TLE is most accurate. Second - (I think) it is the moment in time corresponding to the mean anomaly value in line 2 of the TLE, which is 66.7566 degrees in this example:

TLE = """
1 25544U 98067A   16031.25992506  .00006019  00000-0  97324-4 0  9994
2 25544  51.6430  25.8646 0006733  62.5910  66.7566 15.54344726983528
"""


my question: what is the exact relationship between the epoch time in a TLE and the corresponding time in UTC?

The current difference can also be shown with Skyfield:

from skyfield.api import JulianDate

jd = JulianDate(utc=(2016,1,1))

print jd.tt, "days"
print jd.tt % 1, "day fraction"
print ((jd.tt % 1) - 0.5) * 24. * 3600, "seconds"


gives

2457388.50079 days
0.500789166894 day fraction
68.1840196252 seconds


this NASA page calls the fraction "Julian Day Fraction":

but this Celestrak page states that

"Note that the epoch day starts at UT midnight (not noon) and that all times are measured mean solar rather than sidereal time units (the answer to our third question)."

-
I've asked here about python conversion to computer time: "seconds since epoch" . – uhoh Feb 6 at 8:24

Given: 16031.25992506

The 16 corresponds to 2016. As 1957 was the first year with satellites launched, 57 would be 1957, and in 2057 this might change, as there will be an issue.

The 31 means the 31st day of the year (January 31)

The .25992506 is the fractional day from midnight. This means 6.2382 hours, 14.292 minutes, 17.52 seconds, basically accomplished by multiplying by 24 first, then removing the hours, then 60, then removing the minutes, then 60 again to get the seconds.

As for leap seconds, it isn't actually defined. NASA has stated the practiced standard is:

In practice, it generally holds UTC times, but leap seconds are overloaded onto the first second of the next day.

So the bottom line is, that conversion should give you the time in UTC. Leap seconds are annoying, but the time should still be UTC.

-
The word "Julian" in the NASA page - why is it there? You are saying that the decimal is just "day fraction" in UTC, correct? Why do they add "Julian" to "Day Fraction"? – uhoh Feb 1 at 2:08
Julian refers to the Julian calendar, and is in reference to the day of the year. See en.wikipedia.org/wiki/Julian_day – PearsonArtPhoto Feb 1 at 4:03
got it - thank you for your help! – uhoh Feb 1 at 5:02

The best guess available about the time scale used in TLE files is from the epic Revisiting Spacetrack Report #3 report from Celestrak, which they have put online here:

http://www.celestrak.com/publications/AIAA/2006-6753/

They took the old SGP4 software, collected every single patch and improvement they could find in the dozens of versions online and being passed around various laboratories, and issued a new cleaned up version of the algorithm (the one used in Skyfield, in fact).

In the report's “Section E” they guess that the time is either in UTC or UT1, and conclude that the difference does not really matter because SGP4 just isn't accurate enough in predicting satellite positions for <1 second to matter. (The difference between UTC and UT1 is always less than a second.) They say:

Time accounting within SGP4 is referenced to the epoch of the TLE data. … The time system is assumed here to be UTC, but no formal documentation exists and UTC, as currently defined, was only introduced in 1972. UT1 is needed to calculate GMST for the coordinate transformations discussed in the appendix, but it is unknown whether UT1 or UTC is what is required by the software, although we assume UT1 for this paper. The error associated with approximating UT1 with UTC is within the theoretical uncertainty of the SGP4 theory itself. Except for the GMST calculation, this paper and code assumes time to be realized as UTC.

So you can ignore TAI, TT, and TDB when dealing with satellites. All of the times you deal with will be probably be UTC.

-
This is important, and greatly appreciated. It is good to keep this information threaded with these discussions. Thank you for keeping an eye on Space SE and for Skyfield! To be able to access all of this from a few lines of python script is fantastic! – uhoh Feb 1 at 5:08

The term "Julian day" (or date) has three very distinct meanings. To historians, it typically means a date that is expressed in the Julian calendar, as opposed to the Gregorian calendar. For example, the Julian date 3 September 1752 is the same day as the Gregorian date 14 September 1752. To astronomers, it means the number of days since noon (in some time scale, typically TT or UT) on January 1, 4713 BC (Julian). For example, JD 2357569 is refers to noon UT on 14 September 1752.

The third meaning is the day number of the year, with 1 meaning January 1. This third meaning is the meaning intended at the cited NASA page.

-
Ah, I see! Ok so I am no longer put-off by the use of "Julian" on the NASA page. TLE epochs are in UTC (within about a second as noted above). Thanks! – uhoh Feb 1 at 5:10