BUG: Timestamp(pd.NA) raising TypeError
- [x] closes #45481
- [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/v2.1.0.rst` file if fixing a bug or adding a new feature.

Is it obvious we want to allow this?  If we consider pd.NA as meaningfully distinct from pd.NaT, then silently converting would be wrong I would've thought so - the docs say

> For datetime64[ns] types, NaT represents missing values

and `pd.NA` is what signals missing values. Will check what's done in other cases, not really sure > I would've thought so - the docs say [...] and pd.NA is what signals missing values. Will check what's done in other cases, not really sure

The meaning of "missing" has changed since that doc was written.  In particular NaT has nan-like semantics. > Is it obvious we want to allow this? If we consider pd.NA as meaningfully distinct from pd.NaT, then silently converting would be wrong


I dont have a strong opinion but I'll note:

1. Other na-likes already get converted to NaT (e.g. None -> NaT, NaN -> NaT)

2. The current behavior does seem inconsistent:

```
pd.to_timedelta(pd.NA)  # -> NaT
pd.to_datetime(pd.NA)   # -> NaT
pd.Timedelta(pd.NA)     # -> NaT
pd.Timestamp(pd.NA)     # -> TypeError
```
 > The current behavior does seem inconsistent:

fair enough.  no objection here. This _might_ cause issue if we every introduced a nullable numpy datetime/timedelta types with `pd.NA` as the missing value, but that's not planned right? > This might cause issue if we every introduced a nullable numpy datetime/timedelta types with pd.NA as the missing value, but that's not planned right?

Does the numpy-nullable part matter here?  timestamp[pyarrow] already behaves that way

 > Does the numpy-nullable part matter here? timestamp[pyarrow] already behaves that way

Sure, I was just confirming that there wasn't appetite to have BaseMaskedArray support datetime/timedelta types for example  Thanks @lukemanley 