Deprecating unitless timedelta/datetime
Hi all, I just merged a PR: https://github.com/numpy/numpy/pull/29619 to deprecate unitless timdeldta/datetime64. This is a step in a direction that should be e.g. very helpful for pandas to make timedelta/datetimes less weird. That said, we didn't touch this for a long time, because it is also very hard to really understand how and if users might be impacted. So if you notice this, or maybe even think you may be mixing timedeltas with normal integers/floats a lot you may want to try this branch. This is a `DeprecationWarning`, so it shouldn't out-right break code in production. Note that there are also specific things we could try to make more gentle, even something niche like specifically allowing: `timdelta_arr == 0` (although `timedelta_arr.astype(bool)` should be a plausible replacement as well, I think). Or generally keep allowing `timedelta_arr + integer_arr`, etc. which, with this PR, I believe should give a warning. Cheers, Sebastian
Hi Sebastian, One thing this breaks is the following, which is part of SciPy's testsuite: ``` @pytest.mark.parametrize("dtype", np.typecodes['All']) ... np.eye(2, dtype=dtype) ``` Is there a recommended alternative for downstream libraries who want to test with ~all dtypes easily, but not all dtypes? https://github.com/scipy/scipy/actions/runs/23708171067/job/69063440694?pr=2... Cheers, Lucas ________________________________ From: Sebastian Berg <sebastian@sipsolutions.net> Sent: 29 March 2026 11:37 To: Discussion of Numerical Python <numpy-discussion@python.org> Subject: [Numpy-discussion] Deprecating unitless timedelta/datetime Hi all, I just merged a PR: https://github.com/numpy/numpy/pull/29619 to deprecate unitless timdeldta/datetime64. This is a step in a direction that should be e.g. very helpful for pandas to make timedelta/datetimes less weird. That said, we didn't touch this for a long time, because it is also very hard to really understand how and if users might be impacted. So if you notice this, or maybe even think you may be mixing timedeltas with normal integers/floats a lot you may want to try this branch. This is a `DeprecationWarning`, so it shouldn't out-right break code in production. Note that there are also specific things we could try to make more gentle, even something niche like specifically allowing: `timdelta_arr == 0` (although `timedelta_arr.astype(bool)` should be a plausible replacement as well, I think). Or generally keep allowing `timedelta_arr + integer_arr`, etc. which, with this PR, I believe should give a warning. Cheers, Sebastian _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: lucas.colley8@gmail.com
On Sun, 2026-03-29 at 12:49 +0000, Lucas Colley via NumPy-Discussion wrote:
Hi Sebastian,
One thing this breaks is the following, which is part of SciPy's testsuite:
Hmmmpff, I guess it should not be all that many tests?! There isn't a whole lot you can do with unitless datetimes at least, after all (i.e. you can't even print them, IIRC -- timedelta is a bit better). I can see two paths (besides reverting, which this doesn't seem enough to me). We could improve the helpers here or even just add `typecodes['Numeric']`. I.e. something new in `numpy.testing` that actually lists a specific datetime with unit? Improving `numpy.testing` in this way seems like a sensible thing anyway if we have a good idea. But the main fix is probably that I suspect can probably make `np.dtype("m")` and `np.dtype("M")` specifically work returning a default datetime unit [1]. (I am not actually not sure right now if NumPy has a real default, but pandas has `ns`, so there is one, I guess.) That would mean tests can be changed to just call `np.dtype(typecode)` explicitly (if they otherwise change, `np.eye(, dtype=...)` already has that behavior). Cheers, Sebastian [1] `np.array([np.timedelta64(3, "ns")], dtype="m")` is different, and that already seems to work right without giving a warning.
``` @pytest.mark.parametrize("dtype", np.typecodes['All']) ... np.eye(2, dtype=dtype) ```
Is there a recommended alternative for downstream libraries who want to test with ~all dtypes easily, but not all dtypes?
https://github.com/scipy/scipy/actions/runs/23708171067/job/69063440694?pr=2...
Cheers, Lucas ________________________________ From: Sebastian Berg <sebastian@sipsolutions.net> Sent: 29 March 2026 11:37 To: Discussion of Numerical Python <numpy-discussion@python.org> Subject: [Numpy-discussion] Deprecating unitless timedelta/datetime
Hi all,
I just merged a PR: https://github.com/numpy/numpy/pull/29619 to deprecate unitless timdeldta/datetime64. This is a step in a direction that should be e.g. very helpful for pandas to make timedelta/datetimes less weird.
That said, we didn't touch this for a long time, because it is also very hard to really understand how and if users might be impacted. So if you notice this, or maybe even think you may be mixing timedeltas with normal integers/floats a lot you may want to try this branch.
This is a `DeprecationWarning`, so it shouldn't out-right break code in production.
Note that there are also specific things we could try to make more gentle, even something niche like specifically allowing: `timdelta_arr == 0` (although `timedelta_arr.astype(bool)` should be a plausible replacement as well, I think). Or generally keep allowing `timedelta_arr + integer_arr`, etc. which, with this PR, I believe should give a warning.
Cheers,
Sebastian _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: lucas.colley8@gmail.com _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: sebastian@sipsolutions.net
I think “us” precision would be pretty sensible as a default precision for NumPy. It has a much larger range than “ns” (sufficient to represent all historical human times), and avoids some quirky issues with “ns” precision being unrepresentable in Python’s native datetime types. The two use cases I know for datetimes without a precision currently are for a time delta of 0, and NaT. The later in particular might deserve some thought. On Sun, Mar 29, 2026 at 9:02 AM Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Sun, 2026-03-29 at 12:49 +0000, Lucas Colley via NumPy-Discussion wrote:
Hi Sebastian,
One thing this breaks is the following, which is part of SciPy's testsuite:
Hmmmpff, I guess it should not be all that many tests?! There isn't a whole lot you can do with unitless datetimes at least, after all (i.e. you can't even print them, IIRC -- timedelta is a bit better).
I can see two paths (besides reverting, which this doesn't seem enough to me). We could improve the helpers here or even just add `typecodes['Numeric']`. I.e. something new in `numpy.testing` that actually lists a specific datetime with unit? Improving `numpy.testing` in this way seems like a sensible thing anyway if we have a good idea.
But the main fix is probably that I suspect can probably make `np.dtype("m")` and `np.dtype("M")` specifically work returning a default datetime unit [1]. (I am not actually not sure right now if NumPy has a real default, but pandas has `ns`, so there is one, I guess.)
That would mean tests can be changed to just call `np.dtype(typecode)` explicitly (if they otherwise change, `np.eye(, dtype=...)` already has that behavior).
Cheers,
Sebastian
[1] `np.array([np.timedelta64(3, "ns")], dtype="m")` is different, and that already seems to work right without giving a warning.
``` @pytest.mark.parametrize("dtype", np.typecodes['All']) ... np.eye(2, dtype=dtype) ```
Is there a recommended alternative for downstream libraries who want to test with ~all dtypes easily, but not all dtypes?
https://github.com/scipy/scipy/actions/runs/23708171067/job/69063440694?pr=2...
Cheers, Lucas ________________________________ From: Sebastian Berg <sebastian@sipsolutions.net> Sent: 29 March 2026 11:37 To: Discussion of Numerical Python <numpy-discussion@python.org> Subject: [Numpy-discussion] Deprecating unitless timedelta/datetime
Hi all,
I just merged a PR: https://github.com/numpy/numpy/pull/29619 to deprecate unitless timdeldta/datetime64. This is a step in a direction that should be e.g. very helpful for pandas to make timedelta/datetimes less weird.
That said, we didn't touch this for a long time, because it is also very hard to really understand how and if users might be impacted. So if you notice this, or maybe even think you may be mixing timedeltas with normal integers/floats a lot you may want to try this branch.
This is a `DeprecationWarning`, so it shouldn't out-right break code in production.
Note that there are also specific things we could try to make more gentle, even something niche like specifically allowing: `timdelta_arr == 0` (although `timedelta_arr.astype(bool)` should be a plausible replacement as well, I think). Or generally keep allowing `timedelta_arr + integer_arr`, etc. which, with this PR, I believe should give a warning.
Cheers,
Sebastian _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: lucas.colley8@gmail.com _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: sebastian@sipsolutions.net
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: shoyer@gmail.com
participants (3)
-
Lucas Colley -
Sebastian Berg -
Stephan Hoyer