You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if a datetime holding the NaT value (supported by Numpy and Pandas) is passed to get_position it returns results for 12:12:43 UTC on Tuesday, September 21, 1677!
The bug is introduced by the coercion in get_milliseconds, which returns -9223372036854.775 (ms) for NaT values. This time offset from the UNIX epoch corresponds to the above date in 1677!
# A datetime-like series coerce to int is (always?) in nanoseconds
returndate.astype('int64') /10**6
Instead, it would be great if NaT values were handled gracefully and None or np.nan values were returned instead. Alternatively, an error could be raised indicating that NaT values are unsupported.
The text was updated successfully, but these errors were encountered:
Currently if a datetime holding the NaT value (supported by Numpy and Pandas) is passed to
get_position
it returns results for 12:12:43 UTC on Tuesday, September 21, 1677!Minimum example to reproduce:
Gives:
{'azimuth': Index([-0.9723467728956097, -0.9723467728956097], dtype='float64'), 'altitude': Index([-1.5207425775049375, -1.5207425775049375], dtype='float64')}
The bug is introduced by the coercion in
get_milliseconds
, which returns -9223372036854.775 (ms) for NaT values. This time offset from the UNIX epoch corresponds to the above date in 1677!suncalc-py/suncalc/suncalc.py
Lines 69 to 72 in 6568431
Instead, it would be great if NaT values were handled gracefully and None or np.nan values were returned instead. Alternatively, an error could be raised indicating that NaT values are unsupported.
The text was updated successfully, but these errors were encountered: