15
0
forked from pool/python-ephem

Commit Graph

  • c1b411b140 Accepting request 1287772 from devel:languages:python main Ana Guerrero 2025-06-23 13:05:01 +00:00
  • 832a2626ea - Switch to pyproject macros. Steve Kowalik 2025-06-23 01:33:42 +00:00
  • 6370ff0a03 Accepting request 1223762 from devel:languages:python Ana Guerrero 2024-11-13 14:28:32 +00:00
  • e35973c1b6 Accepting request 1223661 from home:glaubitz:branches:devel:languages:python Markéta Machová 2024-11-12 17:11:05 +00:00
  • 2c679625e8 Accepting request 1130849 from devel:languages:python Ana Guerrero 2023-12-04 22:02:58 +00:00
  • b44f264fe5 - update to 4.1.5: * Add support for Python 3.12. Dirk Mueller 2023-12-04 21:05:37 +00:00
  • 9620412f51 Accepting request 1046298 from devel:languages:python Dominique Leuenberger 2023-01-03 14:05:25 +00:00
  • c026c56fe7 - update to 4.1.4: * A memory leak has been resolved, that was failing to free the storage for the satellite name (a Python string) and catalog number (a Python integer) when the satellite object itself was freed. * In previous versions, if you asked for the position of a body (a) whose elliptical or hyperbolic orbit has an eccentricity very close to 1.0 and (b) which is very far from perihelion, then the underlying C library would print a warning `Near-parabolic orbit: inaccurate result but let your Python script continue on unawares. Now, no message is printed directly to the screen, and instead a RuntimeError will tell you why PyEphem can’t compute the body’s position. * The underlying C library should no longer produce a segmentation fault if given the floating point number NaN as a date. The Python rising and setting logic now also watches out for NaN dates, and raises a ValueError` when one is detected. Dirk Mueller 2023-01-02 19:59:13 +00:00
  • 2e47984286 Accepting request 947073 from devel:languages:python Dominique Leuenberger 2022-01-17 22:48:50 +00:00
  • 3d17d38cba Accepting request 947057 from home:bnavigator:branches:devel:languages:python Matej Cepl 2022-01-17 21:50:38 +00:00
  • 5baa59bff7 Accepting request 947053 from devel:languages:python Dominique Leuenberger 2022-01-17 21:34:33 +00:00
  • 63d4dd833e - update to 4.1.1: * When you provide PyEphem with a Python `datetime that has a time zone attached, PyEphem now detects the time zone and converts the date and time to UTC automatically. * A new search routine had been written and tested to power the :ref:transit-rising-setting methods previous_rising(), previous_setting(), next_rising(), and next_setting(). They should no longer be susceptible to getting hung up in a loop. You should also find them substantially faster. * Fixed the constellation() routine so that it uses astrometric, rather than apparent, right ascension and declination. This should make it more accurate along the borders of each constellation. * Fixed how the underlying “libastro” library computes whether a body’s image is deflected by gravity when its light passes close to the Sun. Previously, users would see coordinates jump unexpectedly as the deflection formula turned on and off haphazardly. * Fixed the star positions in the ephem.stars star catalog by adding 8.75 years of proper motion to each star. Previously, each 1991.25 position from the Hipparcos catalog was being incorrectly treated as a 2000.0 position. * A new routine unrefract() lets you compute the real altitude of a body that you observe in the sky at a given apparent altitude. * The old cities.lookup() function is now officially deprecated. Because of a Google API restriction, it stopped working in 2018. * Planetary moon positions are now available through the year 2040 (previously, asking for a position past 2020 returned zeroes). * The Date` object is improved such that the return values of Dirk Mueller 2022-01-17 20:32:56 +00:00
  • 3a2568cf09 Accepting request 835116 from devel:languages:python Dominique Leuenberger 2020-10-29 08:45:25 +00:00
  • 66fd6de495 Accepting request 730704 from devel:languages:python Dominique Leuenberger 2019-09-23 10:10:32 +00:00