API: default to stdlib timezone objects for fixed-offsets

[jbrockmendel]

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

addresses part of #34916 but does not address non-fixed-offset tzs

[mroeschke]

This made me realize that ZoneInfo doesn't appear to have a concept of a "fixed-offset" timezone.

Are you thinking of still fully pursuing the "default to datetime.timezone" for 2.0? datetime.timezone objects don't contain the tz data info that ZoneInfo has.

IMO in an ideal world it would be nice to default to zoneinfo.ZoneInfo and then use datetime.timezone for fixed timezones, but ZoneInfo is only available in >3.9 and we have to support 3.8 until April 2023

[jbrockmendel]

IMO in an ideal world it would be nice to default to zoneinfo.ZoneInfo and then use datetime.timezone for fixed timezones, but ZoneInfo is only available in >3.9 and we have to support 3.8 until April 2023

Agreed. One option would be to make the changeover in 2.0 for all-but-py38

[jbrockmendel]

Mothballing until we drop py38 so we can do non-fixed tzinfos at the same time. in practice this means 3.0

[MarcoGorelli]

Looks good to me, thanks @jbrockmendel

[mroeschke]

Do we have a test that asserts that Timestamp.utcnow().tz. or Timestamp(..., tz="UTC").tz returns datetime.timezone.utc?

For datetime.__eq__, this compares to equal althought the UTC objects are different

>>> import pytz
>>> import datetime
>>> d1 = datetime.datetime(2022, 1, 1, tzinfo=pytz.UTC)
>>> d2 = datetime.datetime(2022, 1, 1, tzinfo=datetime.timezone.utc)
>>> d1 == d2
True

[jbrockmendel]

Do we have a test that asserts that Timestamp.utcnow().tz. or Timestamp(..., tz="UTC").tz returns datetime.timezone.utc?

no, will update

[mroeschke]

Thanks @jbrockmendel