Repository navigation
Converting ns/as-precision datetime64 to datetime.datetime results in integer #8546
Description
Converting ns/as-precisiong datetime64 to datetime.datetime results in integer:
datetime.datetime does not support nanoseconds (see issue). When numpy casts it should round or raise an error, instead it silently returns int:
In [186]: numpy.datetime64("1985-08-13", "us").astype(datetime.datetime)
Out[186]: datetime.datetime(1985, 8, 13, 0, 0)
In [187]: numpy.datetime64("1985-08-13", "ns").astype(datetime.datetime)
Out[187]: 492739200000000000
In [189]: numpy.datetime64("1985-08-13", "as").astype(datetime.datetime)
Out[189]: -8200712707674996736
Activity
gerritholl commentedon Jan 30, 2017
This is painful because xarray (and pandas, I believe) internally uses nanosecond-precision, which means those cannot be correctly converted to
datetime.datetimeobjects.[-]Converting µs/as-precisiong datetime64 to datetime.datetime results in integer[/-][+]Converting ns/as-precision datetime64 to datetime.datetime results in integer[/+]gerritholl commentedon Jan 30, 2017
More direct illustration:
timedelta64(100, 'ns').item()→100. I understand thatdatetime.datetimeis unable to represent this but I'm not convinced this is the best approach.shoyer commentedon Jan 30, 2017
This is basically the same issue as #7619 and #4337
eric-wieser commentedon Oct 18, 2017
It seems to me that the best approach here is either:
timedelta64(100, 'ns').item() == timedelta64(100, 'ns')is which at least is consistent with float128(0).item() returns numpy.float128 #8547timedelta64(100, 'ns').item() == datetime.timedelta(0)andnp.float128(tiny).item() == 0.0, both emitting warnings about loss of precision due to casting toobject/ callingitem()astype(object)/item()concerns, and have.astype(object)always leave numpy scalars intact.eric-wieser commentedon Feb 18, 2019
Closing as a duplicate of #12550, since there's far more discussion there