(ANSWERED) Convert epochyr and epoch days to the epoch param for sgp4init

[rodriguj-alexva]

Hello,

I am trying to determine how the Satrec fields epochyr and epochdays are converted from epoch ("days since 1949 December 31 00:00 UT") and how to do it backwards. I am using:

epoch = ((2000 + old_satrec.epochyr) * 365 + old_satrec.epochdays) - ((1949 * 365) + 1)

But I think this has a lot of mistakes as at least it does not take into account leap years. I know this is a well known function (computing days between dates) but is there a simple solution in the Skyfield world? I am new to it but I did search the forums with no luck.

And I could look at the source of sg4init but ....

(FYI the ultimate goal is to duplicate a Satrec while changing the RAAN. Duplicate because Satrec objects cannot be modified).

Jose Rodriguez
[email protected]

[brandon-rhodes]

I'd recommend using jdsatepoch and jdsatepochF instead, which added together produce a simple Julian date. By subtracting the JD of 1949 December 31, I think you’ll get the number you want.

[rodriguj-alexva]

OK I will take a look. I found an answer:

https://stackoverflow.com/questions/15226287/how-to-convert-days-into-months-using-datetime-in-python3

Which is close but it does not handle epochdays well which I think includes fractions of a day. Also for some reason, the year is off by 1.

All this because I don't want to do string manipulations on the original TLE lines.

Final question, why are both EarthSatellite and Satrec immutable objects?

[rodriguj-alexva]

Or I would suggest that a Satrec constructor that used epochyr and epochdays would be useful.

[brandon-rhodes]

Or I would suggest that a Satrec constructor that used epochyr and epochdays would be useful.

What use case would they cover that's not covered by using jdsatepoch and jdsatepochF instead — are you running into cases where you can't produce those two numbers?

I'm not expecting to add a new constructor, as sgp4 is intended to merely be a simple wrapper around the C++ library, so my expectation is that we'll continue to offer exactly the routines that the C++ does.