So… this TLE has given me some problems lately… I’m making this post just to document the adventure and leave an open loop and data point for a TLE that was valid for some software but not all.
Brief background
I’ve spent the last couple weeks updating my “shadow archive” of observations metadata, used for e.g. Year Review 2022. I’ve recently finished adding the demoddata information and downloading (most of) the data from those decoded frames, and tagging each frame with the az / el / range vector at that time. Doing so makes generating the following polar histogram of decoded frames take only ~5 seconds to extract, collate, and render: (station #834)
Someone a few years ago generated similar plots (remind me who please!)
Back to this TLE of destiny.
TLE epoch time
The issue is the epoch time of 2023, day 175.2.
PyEphem does not have a problem with this TLE, as evidenced by the observations which used it (them?) and from directly using pyephem in a python REPL:
I used Skyfield for the calculations, mostly as an excuse to play with it and see if/how it would work for SatNOGS. It uses python-sgp4 for its EarthSatellite objects and parsing TLEs.
python-sgp4 chokes on this value, because the day turns out to be 2023-06-24 at 04:47 and 59.999999998137355 seconds. Rounding happens and we get a seconds value of 60 seconds on a date where there certainly was NOT a leap second. Skyfiled thus chokes on the exception and … we are at this post 
My version of sgp4 is apparently NOT using the C++ code, but the pure Python translation:
In [15]: import sgp4.api
In [16]: sgp4.api.accelerated
Out[16]: False
No conclusions
@fredy used @cgbsat strf to fit those elements to prior observations, so by implication strf had no problem with the epoch value. Or perhaps the internal number was OK, but a tiny round-the-unfortunate-direction happend in the printf()?
sgp4 handles the fractional day number with Python’s native divmod() and other non-fancy operations sgp4.functions.days2mdhms(year, days).
I suspect that this could be addressed by checking that the TLE’s values exported from the tool not only is the closest to the tool’s internal values, but also round-trips back from the lower-precision output format. Is this worth the effort? Depends on whether you use import sgp4 or import ephem 
.
When you try to parse and process 57M frames, you are bound to find interesting corner cases!
$ sqlite3 demoddata.db 'select count(*) from obs_demoddata;'
56980995
Hope you enjoyed the read.
