[Numpy-discussion] Deprecating unitless timedelta64 and "safe" casting of integers to timedelta64

[Stephan Hoyer]

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:
https://github.com/numpy/numpy/pull/6465

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 [4]: np.datetime64('2000-01-01T00') + 10
Out[4]: 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
situations.

I'd like to propose deprecating such casting in NumPy 1.11, with the intent
of removing it entirely as soon as practical.

Stephan

[Nathaniel Smith]

Post by Stephan Hoyer
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

Post by Stephan Hoyer
https://github.com/numpy/numpy/pull/6465
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.

Post by Stephan Hoyer
Even worse, we currently support "safe" casting of integers to

timedelta64, which means that integer + datetime64 and integer +

Post by Stephan Hoyer
In [4]: np.datetime64('2000-01-01T00') + 10
Out[4]: 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
situations.

Post by Stephan Hoyer
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.

-n

[Chris Barker]

Post by Stephan Hoyer
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.

this really is odd :-)

Post by Stephan Hoyer
Even worse, we currently support "safe" casting of integers to
timedelta64, which means that integer + datetime64 and integer +

which makes the above even odder -- underlying datetime64 is, "just" a 64
bit int -- so I can see how someone _may_ want to work directly with that
-- but if you can use regular integerts, why have a unitless timedelta?

Based on the principle that NumPy's datetime support should mirror the

Post by Stephan Hoyer
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
situations.
I'd like to propose deprecating such casting in NumPy 1.11, with the
intent of removing it entirely as soon as practical.

Agreed -- I can imagine use-cases, but users can cadt to/from integers if
that's what they want to do e.g. with .astype()

-Chris
--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R [phone] voice
7600 Sand Point Way NE [phone] fax
Seattle, WA 98115 [phone] main reception

***@noaa.gov