BUG: datetime64(np.int64(123), 'ns') fails but datetime64(123, 'ns') is ok

[skaae]

Describe the issue:

converting integers to np.datetime64 fails for numpy np.int64 integers.

np.datetime64(np.int64(123), 'ns')  # ValueError: Could not convert object to NumPy datetime
np.datetime64(123, 'ns')  # ok

Reproduce the code example:

np.datetime64(np.int64(123), 'ns')  # ValueError: Could not convert object to NumPy datetime
np.datetime64(123, 'ns')  # ok

Error message:

np.datetime64(np.int64(123), 'ns')
*** ValueError: Could not convert object to NumPy datetime

NumPy/Python version information:

1.23.2 3.8.10 (default, Jun 22 2022, 20:18:18)
[GCC 9.4.0]

Context for the issue:

No response

[seberg]

Just to note, there is no regression (NumPy 1.19 behaves the same) and conversion works for timedelta.
OTOH, casting from integers to datetime actually is support currently. I am not immediately sure what the desired outcome should be (error or conversion), but it is inconsistent that casting works, but this does not.

[skaae]

I noticed this because I had some trouble changing between pandas timestamps and numpy timestamps. The following might be a bug in how pandas uses numpy timestamps, but is at least inconsistent:

np_ts_from_pd = pd.Timestamp.now().asm8  # numpy.datetime64('2022-09-02T20:21:36.090341000')
print(int(np_ts_from_pd)) # prints ts in nano seconds

np_ts_from_np = np.datetime64('now')  # numpy.datetime64('2022-09-02T18:23:24')
int(np_ts_from_np)  # fails with: int() argument must be a string, a bytes-like object or a number, not 'datetime.datetime'

[seberg]

Oh, great point! The weird behavior has to do with another old issue (and the logic being a maze).

So I think the solution is to explicitly define datetime.__int__() to raise an error, or alternatively, explicitly undefine it. (We might want to deprecate it smoothly just in case, although it does seem rather useless since it seems that it mostly fails.)

The reason for the weird behavior is that datetime.itme() (converting to a "python object") "overflows" and returns an integer rather than a Python datetime. So that ends up doing very different things for the two values!
Unfortunately that is a bit tricky, but the issue is: gh-12550 (it talks about casts, but casts use the .item() logic).

[d-chambers]

I just ran into this same issue. Very confusing.