API: default to stdlib timezone objects for fixed-offsets
- [ ] closes #xxxx (Replace xxxx with the GitHub issue number)
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] 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
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 > 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 Mothballing until we drop py38 so we can do non-fixed tzinfos at the same time.  in practice this means 3.0 > Do we have a test that asserts that Timestamp.utcnow().tz. or Timestamp(..., tz="UTC").tz returns datetime.timezone.utc?

no, will update Thanks @jbrockmendel 