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:
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.
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.
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.