The datetime2et function (added in #284) fails with a SpiceyError when using timezone-aware datetimes, because CSPICE always expects a UTC format without timezone information.
SPICE(INVALIDTIMESTRING) --
Time String Could Not Be Parsed
The input string contains an unrecognizable substring beginning at the character marked by <+>: "2020-01-01T00:00:00<+>00:00"
I have adjusted the implementation of datetime2et so that timezone-aware datetimes are converted to UTC if needed and then the tzinfo is dropped before passing on to SPICE.
Timezone-naive datetimes will still be assumed to be UTC, to stay consistent with the previous behavior. An alternative would be to interpret them as the system local time, which would be correct for use with e.g. datetime.now(), but not for datetime.utcnow().
Coverage increased (+0.0002%) to 99.79% when pulling 1ff76b33bf7e2b4526b3b2e71d64cb3227a5fcbb on johan12345:datetime2et_timezones into 1acb4c1499f12ce2f96787a89f68e9d7cd28ec9d on AndrewAnnex:master.
The
datetime2et
function (added in #284) fails with aSpiceyError
when using timezone-aware datetimes, because CSPICE always expects a UTC format without timezone information.I have adjusted the implementation of
datetime2et
so that timezone-aware datetimes are converted to UTC if needed and then thetzinfo
is dropped before passing on to SPICE.Timezone-naive datetimes will still be assumed to be UTC, to stay consistent with the previous behavior. An alternative would be to interpret them as the system local time, which would be correct for use with e.g.
datetime.now()
, but not fordatetime.utcnow()
.