# What caused the ISS Two Line Element Day of Year problem beginning 12-24-2019?

Does anyone know happened at NORAD or NASA or wherever the published TLEs originate, that caused the ISS TLE wonkiness during the last week of 2019? It did not happen in 2018. What happened? The day of year incremented past 365 days (not a leap year), and the year remained 19 (2019), for computed TLE sets that went into and past the first week of year 2020.

I get my ISS TLE sets from here:

https://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/orbit/ISS/SVPOST.html

and here:

https://tle.info/data/ISS_DATA.TXT

My code now corrects those TLE dates stored in my archive, after two days of rewriting some code to watch for it next time, (and on the upside, it brought my attention to some lurking future problems of my own that are now also fixed). But I would like to know if it was only a hiccup, or is there some change in the format underway, being 'tested'? As of 1/2/2020, the TLEs I received today are now back in the expected format, no longer referenced as days of 2019 beyond 365.

The official word?

Understand, I am very grateful that we have all these wonderful services available, and that I no longer need to squint at the paper reports from Greenbelt, MD, or type them in manually, as was necessary so many years ago (but even then, grateful for that). I would like to know if there are changes in the works that I could be preparing for ahead of time. And a big thank you to all those who maintain the servers and services and software tools so truly appreciated here.

Update 1-2-2020

In response to uhoh's request in the comments, here are three sample TLE sets acquired 12-30-2019, but the problem first seen on 12-24-2019, from the above mentioned links. Note the first one here (which wasn't the first TLE on the webpage, but I'm condensing). It is fine. But the others, of which I show two, have 2019 as the year (of course the leading 20 is not shown in the standard format), but then the day of year is 366 (not a leap year), and then in the last TLE, the day of year is 372? And the year is still 19. What I called 'wonky'.

ISS
1 25544U 98067A   19365.78947330  .00016717  00000-0  10270-3 0  9114
2 25544  51.6407 101.7439 0005315  86.0590 274.1168 15.49502788  5904

ISS
1 25544U 98067A   19366.82137887  .00016717  00000-0  10270-3 0  9129
2 25544  51.6392  96.6358 0005156  88.7140 271.4601 15.49497216  6061

.
.
.

ISS
1 25544U 98067A   19372.17436792  .00016717  00000-0  10270-3 0  9187
2 25544  51.6415  70.1365 0004825 107.1627 253.0051 15.49525362  6890


I modified my code to catch and correct this when reading from my archives, of course also recalculating the checksum, since my archives retain the 'wonky' ones as I first got them. (For those itching to ask the question, Yep, I forgot about recalculating the checksum on the first go.). Here is the processed version of that last set, which now works fine with pyephem (which I am glad bluntly did not like the wrong checksum):

ISS
1 25544U 98067A   20007.17436792  .00016717  00000-0  10270-3 0  9184
2 25544  51.6415  70.1365 0004825 107.1627 253.0051 15.49525362  6890


I'd be happy to provide more details or code, if they would help, but primarily I'm asking if anyone knows if this was only an end of year processing hiccup, like a mini y2k thing, or are there some changes to the format in the works, and they weren't quite ready for prime time? Like most people, I'd prefer to code ahead for a known upcoming change, than to be surprised by it. And that is the partial motive of my question.

Update 1-4-2020:

Now reading spacetrack report #3 for further insight. For those interested, link is here:

As I continue researching this, I continue to hope for and welcome and appreciate more insight from others.

Although I do not yet have my answer, a practical take away from this subject is for others to be aware that the doy > target year's days in a year situation is a possible epoch date that may be encountered in TLEs in the last week of that year, or even beginning the previous year(?! since we have not yet ascertained if there is a fixed hard limit less than 999 before the year is incremented and the doy gets adjusted properly for that year increment), and so one's own code base needs to deal with it wherever it may cause problems, if it does unexpectedly occur. IOTW, write code to expect it.

• @uhoh in response to your comment, I added an update today with some samples. – always_learning Jan 3 at 4:43
• @asdfex after reading several sources providing a key for understanding the data in the various positions of a two line element set, I have not yet encountered any detail such as your It's very common to refer to things like 'day -1' for the last day of the last month or 'October, 34th' to refer to the the third day of November.. I believe I am not the only one who would like it stated more clearly and plainly and officially on the many pages that are there to inform us. Thank you for inspiring a filling of that gap with your comment. – always_learning Jan 3 at 15:20
• If it is indeed, as has been said, "very common", this begs the question, "How far outside standard expected ranges in this context, can one reasonably expect an official tle's epoch date to drift outside the culturally common expected ranges of the Gregorian calendar? Five days? Nine weeks? Less than 999 days?" Is there a document that clarifies this? It might prove to be immensely helpful when designing code and writing tests for that code. – always_learning Jan 3 at 15:22
• @asdfex ok. Understood. My code makes extensive use of such functions. What was unexpected was actual published data straying outside a reasonably expected range, based on documents providing a key to understanding the values, and implying the ranges to be in culturally accepted bounds. A day of year value of 372 for year 2019 is not the normal culturally accepted bounds for days in a Gregorian calendar year. Hence my OP. Is a doy of 372 for 2019 actually better at presenting a clear and non-confusing useability of the data? Even a footnote on a tle format key would help. Yes? – always_learning Jan 3 at 16:06
• @always_learning Just look at the spec. Io and behold, there are multiple. One thing they all have in common is that the epoch is the julian day + fraction, given as three characters in the range [0-9]. So 999 is definitely the largest acceptable number, negative numbers are not allowed. STK also says that the largest permissible value is 366, a restriction that is absent in the NORAD spec. So if you strictly implement the NORAD spec, you are required to allow days up to 999. – Polygnome Jan 3 at 21:10

• +1 "The SGP4 propagator does not actually use the day of year (just time since epoch)..." Wow I never fully realized this until now! Yes a quick check of Revisiting Spacetrack Report #3 shows only zonal harmonics (J2, J3, J4) and no tesserals which would then require knowing absolute time and a model for the rotation of the Earth, and the expressions are always expanded about (t-t_zero). – uhoh Jan 6 at 22:32