`propagate(self, year, month=1, day=1, hour=0, minute=0, second=0.0)` seems kind of wrong and easy to misuse

in particular, one might try to do something like propagate(608400) which might seem reasonable given that the sgp4 function is called assgp4(satrec, seconds_since_epoch) and instead of propagating the satellite a week from the epoch, propagate will try compute for the year 608400.

of course I’d never do something like that… 🤨

Perhaps a better interface for propagate would be propagate(self, obs_time=None, second_since_epoch=None).

If neither obs_time nor seconds_since epoch are given, then propagate would compute at obs_time=datetime.datetime.now() - at the time the function was called. If obs_time is None, and seconds_since_epoch is a real number, then compute based on the epoch of the TLE. If both are given… that should probably be an error because it’s not immediately clear what’s supposed to happen.

[brandon-rhodes]

^ (The commit above, alas, named this issue in error.)

@ckuethe — I new releases in the past week that, following your advice here, have deprecated the propagate() routine. I think you are correct that it raises problems, and is not in the spirit of the SGP4 code that inspired this library (and that it now wraps if a C compiler is available!).

So I’ll go ahead and close this again, but this time for the real reason: that by taking a pure JD as the input, it’s easy for folks to do math on the value, and they can now lean on other libraries to do all kinds of conversions that the values might need.

Let me know if you run into any snags with the new API. Thanks!

[brandon-rhodes]

Wonderful! I’ll keep the issue open, though, because it would be nice to have one or two routines added to the API that provided other options.