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

[shoyer]

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.

[gerritholl]

The behaviour on float128 is also peculiar.

[OmerJog]

Is there any progress with fixing this issue?

[eric-wieser]

@OmerJog: We can't "fix" it until we can come to a decision about what the correct behavior is. I think my preference is for @shoyer's option 1, using the same principle that operator.index(f) is forbidden for all floats, not just non-integral ones.

[h-vetinari]

@eric-wieser: We can't "fix" it until we can come to a decision about what the correct behavior is.

Another option in addition to the OP:
3. don't return datetime.datetime, but rather a np.datetime64

I know this is a large breaking change, but it is still the best behaviour to follow IMO. datetime.datetime are not well-embedded nor compatible in many different (performance-relevant) ways with numpy/pandas etc. Just rip off the old crusty bandaid (which is not to say that the change cannot be carefully planned/managed/executed).

[eric-wieser]

@h-vetinari's suggestion is not a terrible one, and is at least somewhat consistent with how longdouble behaves. On the other hand, there's little point calling item in the first place if you're happy with a numpy scalar.

Which of the following does the suggestion apply to?

• All datetime types
• All datetime types with higher precision than datetime.datetime
• Any datetime value that falls out of range of a datetime.datetime

[h-vetinari]

My suggestion applies to all datetime types**. And the ramifications (intentionally) don't stop at .item cf. #12550.

** probably timedeltas too? Actually I tend to think that .item should probably not cast in general, but e.g. for ints / floats this is probably biting off more than we want to chew.

[eric-wieser]

Actually I tend to think that .item should probably not cast in general

I'm starting to think the answer is "then don't use item". You can get the semantics you want with:

def scalar_from(arr):
    return arr.squeeze(axis=range(axis.ndim))[()]

or if you don't care for the weird semantics we're trying to deprecate in #10615,

def scalar_from(arr):
    assert arr.ndim == 0
    arr[()]

[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?

[eric-wieser]

That perhaps then is the change to make - changing the meaning of astype(object). Although I can perhaps see that opens a can of worms.

[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).