Is this backwards compatible?

Currently only timezone objects are allowed, and timezone is a subclass of tzinfo so I'd say yes it is.

Also, should I add a Changed in 0.x.x in the readme?

Yes please add the changed section

Codecov Report

Merging #56 (a1728fa) into main (18584df) will not change coverage.
The diff coverage is 100.00%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@           Coverage Diff           @@
##             main      #56   +/-   ##
=======================================
  Coverage   94.76%   94.76%           
=======================================
  Files           2        2           
  Lines         210      210           
  Branches       30       30           
=======================================
  Hits          199      199           
  Misses          9        9           
  Partials        2        2           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@Viicos or @Zac-HD should we additionally or instead support integer second offsets? Pydantic can't really validate against string time zones, at least not easily.

cc @sydney-runkle

Per pydantic/pydantic#8088 (comment), IMO we should not.

Offsets are a fundamentally different datatype than timezones: the UTC offset of a timezone changes with every daylight savings transition, as well as at other times when the tz rules are changed.

Furthermore, offsets are very very very rarely the right solution to a problem, making them an attractive nuisance which causes far more trouble in bugs than it saves in the few cases where it's the right way. I think you can cover most reasonable cases with ZoneInfo.key, treating a zero-utc-offset tzinfo as UTC, and requiring users to write custom validators for other cases.