pytz

Pytz has been the timezone workhorse for Python for years, and it works reliably once you understand its quirks. The main gotcha is the non-standard `localize()` and `normalize()` pattern - you can't just pass a pytz timezone to `datetime()` constructor like you'd expect. This causes subtle bugs that are hard to debug, especially with DST transitions.

The API feels dated compared to modern Python standards. You need to remember to use `tz.localize(dt)` instead of `dt.replace(tzinfo=tz)`, and `tz.normalize()` after arithmetic operations. These aren't intuitive, and the error messages won't help you understand what went wrong. Type hints are minimal, so IDEs provide little guidance.

For Python 3.9+, the standard library's `zoneinfo` module offers a much more ergonomic API with proper datetime constructor support. Pytz remains necessary for older Python versions or projects already using it, but migration guides are sparse and the transition can be tricky.

Using pytz daily means dealing with its non-intuitive `localize()` and `normalize()` methods instead of simply passing tzinfo objects to datetime constructors. The API violates the principle of least surprise—naive datetime arithmetic with pytz timezones silently produces wrong results unless you normalize afterward. This has bitten me in production more than once, particularly around DST transitions.

Performance-wise, pytz loads timezone data lazily which helps memory usage, but the startup cost is negligible anyway. No connection pooling concerns since it's pure data manipulation. Error handling is minimal—invalid timezone names raise KeyError, not a custom exception, making defensive coding awkward. No built-in retry logic (not applicable here) but also no hooks for observability—you're on your own for tracking timezone conversion metrics.

The real issue is that Python 3.9+ has `zoneinfo` in the standard library, which uses the datetime-native tzinfo interface correctly. If you're on modern Python, there's little reason to add pytz as a dependency. It's only essential for Python 3.8 and earlier, or when you need the IANA database bundled rather than relying on system tzdata.

pytz has been the go-to timezone library for years, but it has a steep learning curve due to its non-Pythonic API. The biggest gotcha is that you can't just pass a pytz timezone to datetime's constructor - you must use `localize()` for naive datetimes and `normalize()` after arithmetic. Using the straightforward approach silently gives wrong results with DST transitions, which is incredibly frustrating to debug.

The documentation exists but doesn't emphasize these critical pitfalls enough. I've seen countless Stack Overflow questions from developers who thought `datetime(2023, 3, 15, tzinfo=pytz.timezone('US/Eastern'))` would work correctly. The error messages don't help either - pytz will happily accept incorrect usage and produce subtly wrong results rather than failing fast.

That said, when you know the patterns, it's reliable and comprehensive. Python 3.9+ added zoneinfo to the standard library which has a more intuitive API, and I'd recommend that for new projects. pytz is still necessary for Python < 3.9 or when you need the absolute latest timezone database updates.