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"


2457388.50079 days
0.500789166894 day fraction
68.1840196252 seconds

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

NASA TLE 2line.gif

NASA TLE screenshot

but this Celestrak page states that

Celestrak TLE screenshot

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

  • $\begingroup$ I've asked here about python conversion to computer time: "seconds since epoch" . $\endgroup$ – 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.

  • $\begingroup$ 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"? $\endgroup$ – uhoh Feb 1 '16 at 2:08
  • 2
    $\begingroup$ Julian refers to the Julian calendar, and is in reference to the day of the year. See en.wikipedia.org/wiki/Julian_day $\endgroup$ – 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:


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.

  • $\begingroup$ 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! $\endgroup$ – uhoh Feb 1 '16 at 5:08

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.


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.

  • $\begingroup$ 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! $\endgroup$ – uhoh Feb 1 '16 at 5:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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