BUG: .item() on a 0-dimensional datetime64[ns] array yields an integer

This is obviously not useful:

In [4]: np.array(np.datetime64('2000-01-01', 'us')).item()
Out[4]: datetime.datetime(2000, 1, 1, 0, 0)

In [5]: np.array(np.datetime64('2000-01-01', 's')).item()
Out[5]: datetime.datetime(2000, 1, 1, 0, 0)

In [6]: np.array(np.datetime64('2000-01-01', 'ns')).item()
Out[6]: 946684800000000000

The underlying issue is that not all datetime64 types can be represented in datetime.datetime objects, which have fixed us precision.

We should either:

1. Raise TypeError in all cases when calling .item() on a datetime64[ns] array.
2. Convert to datetime.datetime if it can be done safely, raise ValueError otherwise.

My preference is for 2.

[h-vetinari]

I’m starting to think the answer is “then don’t use item”.

Fair, but apparently .astype (which I do need to use) follows .item-semantics. And how far I’d personally turn the dial of “not casting” shouldn’t change the fact that the proposal makes sense for datetimes, no?

[h-vetinari]

Also fair, but probably better discussed in #12550.

In this sense, it’s good to have separate issues, because even if astype(object) were fixed to follow different semantics, the problem of the OP here would persist (so not exactly duplicate).