BUG: Raise when casting NaT to int
State: closed

- [x] tests added / passed
- [x] passes `black pandas`
- [x] whatsnew entry

Fixes a bug in `astype_nansafe` where `NaT` was ignored when casting a datetime or timedelta to `int`.  I put the test in `pandas/tests/dtypes/test_common.py` since I couldn't find another place where `astype_nansafe` was tested.  Also adds various other tests for `astype_nansafe`.

Related: https://github.com/pandas-dev/pandas/pull/28438

Labels:
name: Dtype Conversions
description: Unexpected or buggy dtype conversions

Comments:
is there a user visible level that hits this?
This hits both Series.astype, Index.astype, and DataFrame.astype

```python

In [6]: a = [pd.Timestamp('2000'), pd.NaT]

In [7]: pd.Series(a).astype(int)
Out[7]:
0     946684800000000000
1   -9223372036854775808
dtype: int64

In [8]: pd.Index(a).astype(int)
Out[8]: Int64Index([946684800000000000, -9223372036854775808], dtype='int64')

In [10]: pd.DataFrame({"a": a}).astype(int)
Out[10]:
                     a
0   946684800000000000
1 -9223372036854775808
```

In addition to the `astype_nansafe` unit tests, we'd ideally also test these user facing ones.

And we should double check: we want this behavior right? Some people *may* be relying on this behavior (treating `pd.NaT` as `iNaT`). This feels like a bigger change than https://github.com/pandas-dev/pandas/pull/28438/files. I might prefer a warning first that this will change (though how would people work around it?).
Did we decide on whether we're going to deprecate this behavior before changing it? IMO, ew should
> Did we decide on whether we're going to deprecate this behavior before changing it? IMO, ew should

I'd defer to you guys on that one.  If we deprecate, the change would be to use a deprecation warning instead of an error and xfail the tests?
> Did we decide on whether we're going to deprecate this behavior before changing it? IMO, ew should

@TomAugspurger you feel strongly about this? I don't think its a big deal, but we could deprecate.
Not *too* strongly, just a slight preference. I could go either way.

On Thu, Sep 26, 2019 at 9:28 AM Jeff Reback <notifications@github.com>
wrote:

> Did we decide on whether we're going to deprecate this behavior before
> changing it? IMO, ew should
>
> @TomAugspurger <https://github.com/TomAugspurger> you feel strongly about
> this? I don't think its a big deal, but we could deprecate.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/28492?email_source=notifications&email_token=AAKAOIT4X7EAX2U27B7IYLDQLTBH7A5CNFSM4IXYP7Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7VYO7I#issuecomment-535529341>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAKAOIXMNRQ27VC6JNSNIRLQLTBH7ANCNFSM4IXYP7ZQ>
> .
>

Given how unusual the current behavior is, I'd be surprised if anyone was relying on it.  I'd say it's more likely to be a source of unexpected bugs.
Is there a legitimate use case for using `astype` that we know of? The rules here wouldn't even match numpy right?

Does seem kind of buggy so I think OK without deprecation too
@dsaxton can you merge master to be sure? I think we can move forward with this as is, unless @TomAugspurger you feel otherwise
can you merge master
@jreback all green - OK to merge?
can you merge master and we'll look again
lgtm. @jbrockmendel if you'd have a glance (and merge if ok)
thanks @dsaxton