ENH: add `__from_pyarrow__` support to `DatetimeTZDtype`
- [x] 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).
- [x] 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.

Closes #52200
Any additional feedback on this? All checks have been green, and it's aligned with what we do for the other Extension Dtypes. I'd like to see more buy-in on ignoring iNaT I would be okay with ignoring iNaT for now. Would be good to write a comment in `__from_arrow__` Thanks @mroeschke @jbrockmendel I've added a docstring to `__from_arrow__` clarifying the `iNaT` behavior. Looks like a merge conflict otherwise LGTM Looks like `test_astype_from_non_pyarrow` is failing the pyarrow nightly build. Possibly this changes something with the upcoming pyarrow release? > Looks like test_astype_from_non_pyarrow is failing the pyarrow nightly build. Possibly this changes something with the upcoming pyarrow release?

Thanks for the FYI. Looks like maybe some different assumptions about timezones in latest pyarrow? I'll investigate. Possible bug with: https://github.com/apache/arrow/pull/34270 ? If the timezones aren't the same (or UTC and naive) then it shouldn't be no-copy, right? @mroeschke I think I found the issue. I don't think I should be calling `tz_localize`, but there was a bug where the units weren't being copied over from the DatetimeArray constructor that I vaguely recall trying to work around. Should be fixed now. Thanks for sticking with this @tswast 