Handle deprecation of naive datetime functions like utcnow() #185
Conversation
Following the deprecation of utcnow in Python 3.12, we add a tzinfo timezone argument to date utils. For now this defaults to None so as not to break comparisons against existing naive datetimes. If and when naive datetimes are fully deprecated in a future Python release, we can change the default argument for tzinfo from None to timezone.utc.
|
All good and ready for review. To verify, go to Python 3.12 CI run test output and verify that no datetime-related deprecation notices are present. |
- Remove deprecated utcfromtimestamp() - Feed timezone-aware datetime to utcttimetuple() to avoid unexpected results
|
Doesn't the WARC standard require utc? From looking at my crawler-that-uses-warcio I appear to have forced everything to UTC already, but then again my side-gig is astronomy. |
Hi Greg, the question here is less about UTC vs other timezones and more about Python's naive vs aware datetime types. Miguel Grinberg has a pretty good blog post about how exactly this issue came about: https://blog.miguelgrinberg.com/post/it-s-time-for-a-change-datetime-utcnow-is-now-deprecated With this PR, by default naive datetimes representing UTC will continue to be used, or for a UTC aware timezone a user can pass in |
|
@ikreymer @wumpus Since Greg had a good point that the WARC spec always expects UTC, I changed the |
Fixes #163
The approach taken follows the advice in #163 (comment) of returning naive datetimes by default, but (and this is a little different than suggested) allowing callers to specify
tz_aware=Trueto receive an aware datetime withtzinfo=datetime.timezone.utc. This should prevent comparison errors between naive and aware datetimes for now while giving us a clear path forward if and when naive datetimes are fully deprecated in a future Python version.