Pandas NaT times cause unexpected behaviour

[GalenReich]

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:

import pandas as pd
from suncalc import get_position

# Create DatetimeIndex containing NaTs
test_pandas_df = pd.to_datetime([None, None], unit="s", utc=True) 

print(get_position(test_pandas_df, 0, 0))

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

	# Pandas series of Pandas datetime objects
	if pd and pd.api.types.is_datetime64_any_dtype(date):
	# A datetime-like series coerce to int is (always?) in nanoseconds
	return date.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.

[kylebarron]

A pull request would be welcome. I don't have the bandwidth to make updates here myself now