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

Chris Barker chris.barker at noaa.gov
Tue Oct 13 18:24:36 EDT 2015

On Tue, Oct 13, 2015 at 10:48 AM, Stephan Hoyer <shoyer at gmail.com> wrote:

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

> Even worse, we currently support "safe" casting of integers to
> timedelta64, which means that integer + datetime64 and integer +
> timedelta64 arithmetic works:

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
> 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()



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20151013/9a90707b/attachment.html>

More information about the NumPy-Discussion mailing list