Repository navigation
BUG: .item() on a 0-dimensional datetime64[ns] array yields an integer #7619
Description
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:
- Raise
TypeErrorin all cases when calling.item()on a datetime64[ns] array. - Convert to
datetime.datetimeif it can be done safely, raiseValueErrorotherwise.
My preference is for 2.
Activity
gerritholl commentedon Jan 30, 2017
The behaviour on
float128is also peculiar.OmerJog commentedon Oct 7, 2019
Is there any progress with fixing this issue?
eric-wieser commentedon Oct 7, 2019
@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 allfloats, not just non-integral ones.h-vetinari commentedon Dec 2, 2019
Another option in addition to the OP:
3. don't return
datetime.datetime, but rather anp.datetime64I know this is a large breaking change, but it is still the best behaviour to follow IMO.
datetime.datetimeare 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 commentedon Dec 2, 2019
@h-vetinari's suggestion is not a terrible one, and is at least somewhat consistent with how
longdoublebehaves. On the other hand, there's little point callingitemin the first place if you're happy with a numpy scalar.Which of the following does the suggestion apply to?
datetime.datetimedatetime.datetimeh-vetinari commentedon Dec 2, 2019
My suggestion applies to all datetime types**. And the ramifications (intentionally) don't stop at
.itemcf. #12550.** probably timedeltas too? Actually I tend to think that
.itemshould probably not cast in general, but e.g. for ints / floats this is probably biting off more than we want to chew.eric-wieser commentedon Dec 2, 2019
I'm starting to think the answer is "then don't use item". You can get the semantics you want with:
or if you don't care for the weird semantics we're trying to deprecate in #10615,
h-vetinari commentedon Dec 2, 2019
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 commentedon Dec 2, 2019
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 commentedon Dec 2, 2019
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).