[Numpy-discussion] Deprecating unitless timedelta64 and "safe" casting of integers to timedelta64
njs at pobox.com
Tue Oct 13 17:17:12 EDT 2015
On Oct 13, 2015 10:48 AM, "Stephan Hoyer" <shoyer at gmail.com> wrote:
> As part of the datetime64 cleanup I've been working on over the past few
days, I noticed that NumPy's casting rules for np.datetime64('NaT') were
not working properly:
> This led to my discovery that NumPy currently supports unit-less
timedeltas (e.g., "np.timedelta64(5)"), which indicate some sort of generic
time difference. The current behavior is to take the time units from the
other argument when these are used in a binary operation.
> Even worse, we currently support "safe" casting of integers to
timedelta64, which means that integer + datetime64 and integer +
timedelta64 arithmetic works:
> In : np.datetime64('2000-01-01T00') + 10
> Out: numpy.datetime64('2000-01-01T10:00-0800','h')
> Based on the principle that NumPy's datetime support should mirror the
standard library as much as possible, both of these behaviors seem like a
bad idea. We have datetime types precisely to disambiguate these sort of
> I'd like to propose deprecating such casting in NumPy 1.11, with the
intent of removing it entirely as soon as practical.
Makes sense to me.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion