Closed souch3 closed 2 years ago
Yes, this is correct, it now uses the Python 3 standard library timezones instead of pytz.
The new 4.0b3 release uses a shim that is backwards compatible with pytz, so localize() should work there, but a with a deprecation warning.
4.0 is released, so this should no longer be an issue, I hope.
localize
was able to be called to interpret a naive datetime as the local time zone. With the latest release, that call raises an AttributeErrorI suspect this is due to a change in the return type to being backports.zoneinfo.ZoneInfo. I believe it used to be a pytz object? I'm assuming this is behaving correctly and we should switch our code to use
astimezone
but confirming here