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

[Nathaniel Smith]

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:
> 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.

Makes sense to me.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20151013/931d3729/attachment.html>