Closed vytas7 closed 1 month ago
Sprintign on this one rn.
Looking into the time_formats
allowed for checking there is one time format here, namely '%a %b %d %H:%M:%S %Y'
, which
would allow for non-timezone-awareness.
How should we handle that?
UTC
or GMT
→ ambiguity what the "correct" choice is
→ extra breaking change in addition to the overall breaking changeRe these alternative datetime formats, I think we can break them quite liberally since they are already hidden by the obs_date
parameter (defaults to False
).
Matching timezones, except UTC/GMT and the locally defined one, is an ongoing problem see here.
So without using a package, like the popular pytz library, it is not yet possible to parse any other timezone.
Acoording to the third paragraph here "An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)." There shouldn't really be any date incoming which is not in GMT/UTC.
In line with the upstream deprecation of
utcnow()
in Python 3.12, I think that we should changehttp_date_to_dt()
to return a timezone-aware datetime. Since HTTP dates are normally in GMT, we could use our ownGMT
zone, or simply use UTC.This is a breaking change of relatively low value, so unfortunately we won't be able to prioritize it for 4.0. (And we need a longer deprecation window in any case.)