# 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 '16 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 '16 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 '16 at 4:03

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 '16 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 '16 at 5:10

Celestrak states that time is UT.

UT is astronomical (more precisely rotational) time. It is determined by observations dependent on earth's rotation and is conventionally related to apparent sidereal time. The conventions are chosen keep UT synchronized with the sun.

The United States Naval Observatory http://aa.usno.navy.mil/faq/docs/UT.php says this about UT:

In astronomical and navigational usage, UT often refers to a specific time called UT1, which is a measure of the rotation angle of the Earth as observed astronomically. It is affected by small variations in the rotation of the Earth. UT1 is a modern form of mean solar time on the Greenwich meridian. Times which may be labeled "Universal Time" or "UT" in data provided by the Astronomical Applications Department of the U.S. Naval Observatory (for example, in the annual almanacs) conform to this definition.

However, in the most common civil usage, UT refers to a time scale called "Coordinated Universal Time" (abbreviated UTC), which is the basis for the worldwide system of civil time.

The offsets between UT and UTC is always in the range -0.9 to 0.9 seconds. UT runs more slowly than UTC, so positive leap seconds (the only kind ever used to date) gives UT a chance to catch up. When UTC is getting more than about 0.5 seconds ahead of UT, a leap second is inserted, after which UT leads UTC by about half a second. Don't worry, UTC will catch up in about nine months. https://www.nist.gov/pml/time-and-frequency-division/atomic-standards/leap-second-and-ut1-utc-information

The rules used by NORAD for updating a TLE are that when the current position of a satellite based on the latest measurements differs from the SPG4 prediction based on the last set of published TLE by more than 5 kilometers, the TLE are updated. The accuracy of SPG4/TLE predictions is another topic.

Orbital kinematics ignore leap seconds. One should propagate a satellite's position using SI seconds in SPG4. If time between the epoch specified in the TLE and pre-or-post-diction spans a leap second, the users must be able to account for that.

• Thanks! Is your answer in any way inconsistent with this answer? – uhoh Feb 4 '18 at 16:17
• I think the use of the term "Julian Day" in descriptions of TLE is confusing and unnecessary. 1.) Stick with the term "Day of Year", where December 31, 2017 00:00 HR is day 0.0 of 2018. 2.) See original post for treatment of leap seconds. TLE and SPG4 ignore leap seconds. Only use them for translation for epoch in DoY to UT1 and translation of prediction in UT1 to UTC for your application. FWIW, I did analysis of radar data resulting from the collision of a Kosmos satellite with an Iridium, and my "post diction" for point of closest approach was 70 meters, using my approach. – Jim De Camp Feb 5 '18 at 17:16
• OK thanks! Yes "Day of Year" is certainly clearer/less ambiguous for me. fyi What would be a “big picture” understanding of how the orbits of Earth satellites are monitored? still needs an answer, as does “Deep space” corrections in SGP4; how does it account for the Sun's and Moon's gravity?. – uhoh Feb 5 '18 at 22:46
• – uhoh Feb 5 '18 at 22:46
• For an object not bound to earth mean motion would be 0.0. TLE can only model keplerian (elliptical) orbits. Humanity Star (cruel misnomer!) passes overhead everywhere on earth several times a day. You can only see it near twilight, when the satellite is illuminated by the sun, and the sun is below the horizon. Go here: n2yo.com/?s=43166 – Jim De Camp Feb 7 '18 at 14:54