BUG: Raise TypeError when subracting DateTimeArray and other date types
State: closed

- [x] closes #59571 (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.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.


Labels:
name: Datetime
description: Datetime data dtype
name: Error Reporting
description: Incorrect or improved errors from pandas
name: Timedelta
description: Timedelta data type
name: Stale

Comments:
@rhshadrach - can you verify if my implementation here is correct? I'm not sure of this. A bit of guidance could be useful. Thanks
```python
        from pandas.core.arrays import DatetimeArray

        datetime_result = self - other
        if isinstance(datetime_result, DatetimeArray):
            raise TypeError(
                "TypeError: unsupported operand type(s) for -: "
                f"'{type(self).__name__}' and '{type(other).__name__}'"
            )
        return -(datetime_result)
```

I added an outside top-level import because I am experiencing `Unbound` errors with `Datetimearray` in this line exactly:
```python
        if isinstance(datetime_result, DatetimeArray):
```
<br>

Also, I replaced the messages with the variable type as any wildcard `.*`. Because I had trouble matching the exact dtype of the variable vs the error output. Seems like the dtype gets converted. For example, there are instances where `timedelta` variable error message contains `timedelta64` but there are cases where it returns `timedelta` as normal.

```python
            r"TypeError: unsupported operand type\(s\) for -: 'DatetimeArray' and '.*'"
```
@mroeschke - could you review this. Thanks
My implementation ~raises~ re-raises new message in `TypeError` on `DateTimeArrays` only. 

Since there are already other error messages for other dtypes like
```python
Cannot subtract tz-naive and tz-aware datetime-like objects.
```
If I implement it as
```python
try:
    return -(self - other)
except TypeError as e:
    raise TypeError(
        "Unsupported operand type(s) for -: "
        f"'{type(self).__name__}' and '{type(other).__name__}'"
    ) from e
```
I would have to fix all tests related to raising `tz-naive/tz-aware` datetime-like objects. Thoughts?
Looks like my previous commit affects other datetime related operations.

Could you give me ideas on catching the error? From my understanding, when a datetime objects go into this block
```python
return -(self - other)
```
It will always raise a `TypeError`. So my previous implementation catches it before doing the operation.
```python
        # We get here with e.g. datetime objects
        from pandas.core.arrays import DatetimeArray

        datetime_result = self - other
        if isinstance(datetime_result, DatetimeArray):
            raise TypeError(
                "Unsupported operand type(s) for -: "
                f"'{type(self).__name__}' and '{type(other).__name__}'"
            )
        return -(datetime_result)
```
Though from checking the CI failures, I can't seem to trace/ I'm not familiar how my latest commit affected them. 

Guidance would be helpful. Thank you!

This pull request is stale because it has been open for thirty days with no activity. Please [update](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request) and respond to this comment if you're still interested in working on this.
It appears this PR has gone stale. If you're interested in continuing @KevsterAmp, merge main, address comments, and the fixup the test failures above, and we'd be more than happy to reopen.