Replace pytz with zoneinfo

[FabioRosado]

Pull Request Checklist

Resolves: #2958

• Ensured tests pass and (if applicable) updated functional test output
• Conformed to code style guidelines by running appropriate linting tools
• Added tests for changed code
• Updated documentation for changed code

Hello folks, I've tried to work on the issue to replace pytz with zoneinfo, although the iso tests are failing and I wonder if you could give me a hand figuring out why.

The test says that the expected value is:

SafeDatetime(1997, 7, 16, 19, 20, tzinfo=tzoffset(None, 3600))

But received:

SafeDatetime(1997, 7, 16, 19, 20, tzinfo=backports.zoneinfo.ZoneInfo(key='CET'))

It seems that the issue is the tzinfo which is different, but SafeDatetime isn't set a tzinfo. Should it? 🤔

Thank you for the help

[avaris]

Well... Looks like at these dates CET is in summer time (CEST) and it's UTC+2. I guess the tests were wrong, these should be 1997-07-16T19:20+02:00 instead? Timezones... 😕

[avaris]

Maybe it's better to move these dates to regular CET instead, e.g. December (1997-12-16T...). It might be confusing to see CET and +2 at first glance.

[FabioRosado]

That makes sensse, although the tests will still fail since we are setting the tzinfo to CET but when we are comparing the values, we don't have the tzinfo, so the expected isn't the same as the value.

I believe the +1 was just a way to maybe set the tz automatically?

The odd thing here is that I testing this with pytz and the test should have failed since the tzinfo isnt being set either 🤔

[avaris]

Timezones and UTC offsets are more or less interchangeable. In other words, a datetime with a timezone set should compare equal to an ISO date with appropriate UTC offset (+01:00 etc). Tests are failing not because one has timezone and the other doesn't, but because pytz and zoneinfo calculate offsets differently. And in this case zoneinfo is correct, offset should be +02 due to summer time.

[avaris]

Further on timezones, main difference is that timezones are dynamic and ISO offset is static. And by dynamic, I mean stuff like summer time or countries/timezones shift offsets due to government decisions over time, etc. So a timezone would calculate (or more like lookup from a database) the correct offset based on the date.

[FabioRosado]

That makes sense, the issue with the test is that the check of equality fails. It's a bit odd that with pytz the test is passing since it returns the same value that TZ=(None, 3600)

[avaris]

Yes, and that was wrong. It should be 7200 sec, because it's summer time for CET for those dates. It looks like a bug in pytz and tests seem to be written with that bug in place. That's why I said the tests should say +02 or we should move out of the summer time and keep +01 (i.e. December).