Re: Deprecating unitless timedelta/datetime
Stephan Hoyer via NumPy-Discussion <[email protected]> Sun, 29 Mar 2026 11:07:58 -0700
| Newsgroups | gmane.comp.python.numeric.general |
|---|---|
| Message-ID | <CAEQ_Tve8qHXpF2+iv4ob79hwfo8Af7V8uF+Ku3xb_178Bq4Lfg@mail.gmail.com> |
--===============1210754223206558946==
Content-Type: multipart/alternative; boundary="000000000000e1b6e4064e2d9d77"
--000000000000e1b6e4064e2d9d77
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I think =E2=80=9Cus=E2=80=9D precision would be pretty sensible as a defaul=
t precision for
NumPy. It has a much larger range than =E2=80=9Cns=E2=80=9D (sufficient to =
represent all
historical human times), and avoids some quirky issues with =E2=80=9Cns=E2=
=80=9D precision
being unrepresentable in Python=E2=80=99s 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=E2=80=AFAM Sebastian Berg <sebastian@sipsoluti=
ons.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=3D...)` already has
> that behavior).
>
> Cheers,
>
> Sebastian
>
>
> [1] `np.array([np.timedelta64(3, "ns")], dtype=3D"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=3Ddtype)
> > ```
> >
> > 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?p=
r=3D24921
> >
> > Cheers,
> > Lucas
> > ________________________________
> > From: Sebastian Berg <[email protected]>
> > Sent: 29 March 2026 11:37
> > To: Discussion of Numerical Python <[email protected]>
> > 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 =3D=3D 0` (although `timedelta_arr.astype(bool)` should b=
e
> > 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 -- [email protected]
> > To unsubscribe send an email to [email protected]
> > https://mail.python.org/mailman3//lists/numpy-discussion.python.org
> > Member address: [email protected]
> > _______________________________________________
> > NumPy-Discussion mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > https://mail.python.org/mailman3//lists/numpy-discussion.python.org
> > Member address: [email protected]
> _______________________________________________
> NumPy-Discussion mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3//lists/numpy-discussion.python.org
> Member address: [email protected]
>
--000000000000e1b6e4064e2d9d77
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">I think =E2=80=9Cus=E2=80=9D precision would be pretty se=
nsible as a default precision for NumPy. It has a much larger range than =
=E2=80=9Cns=E2=80=9D (sufficient to represent all historical human times), =
and avoids some quirky issues with =E2=80=9Cns=E2=80=9D precision being unr=
epresentable in Python=E2=80=99s native datetime types.</div><div dir=3D"au=
to"><span style=3D"font-family:-apple-system,sans-serif"><br></span></div><=
div dir=3D"auto"><span style=3D"font-family:-apple-system,sans-serif">The t=
wo use cases I know for datetimes without a precision currently are for a t=
ime delta of 0, and NaT. The later in particular might deserve some thought=
.</span><br></div><div><br><div class=3D"gmail_quote gmail_quote_container"=
><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 29, 2026 at 9:02=E2=80=
=AFAM Sebastian Berg <<a href=3D"mailto:[email protected]">seba=
[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">On Sun, 2026-03-29 at 12:49 +0000, Lucas Colley via NumPy-Discussion<br>
wrote:<br>
> Hi Sebastian,<br>
> <br>
> One thing this breaks is the following, which is part of SciPy's<b=
r>
> testsuite:<br>
> <br>
<br>
Hmmmpff, I guess it should not be all that many tests?!=C2=A0 There isn'=
;t a<br>
whole lot you can do with unitless datetimes at least, after all (i.e.<br>
you can't even print them, IIRC -- timedelta is a bit better).<br>
<br>
I can see two paths (besides reverting, which this doesn't seem enough<=
br>
to me). We could improve the helpers here or even just add <br>
`typecodes['Numeric']`. I.e. something new in `numpy.testing` that<=
br>
actually lists a specific datetime with unit?=C2=A0 Improving<br>
`numpy.testing` in this way seems like a sensible thing anyway if we<br>
have a good idea.<br>
<br>
But the main fix is probably that I suspect can probably make<br>
`np.dtype("m")` and `np.dtype("M")` specifically work r=
eturning a<br>
default datetime unit [1].<br>
(I am not actually not sure right now if NumPy has a real default, but<br>
pandas has `ns`, so there is one, I guess.)<br>
<br>
That would mean tests can be changed to just call `np.dtype(typecode)`<br>
explicitly (if they otherwise change, `np.eye(, dtype=3D...)` already has<b=
r>
that behavior).<br>
<br>
Cheers,<br>
<br>
Sebastian<br>
<br>
<br>
[1] `np.array([np.timedelta64(3, "ns")], dtype=3D"m")` =
is different, and<br>
that already seems to work right without giving a warning.<br>
<br>
<br>
<br>
> ```<br>
> @pytest.mark.parametrize("dtype", np.typecodes['All'=
])<br>
> ...<br>
> np.eye(2, dtype=3Ddtype)<br>
> ```<br>
> <br>
> Is there a recommended alternative for downstream libraries who want<b=
r>
> to test with ~all dtypes easily, but not all dtypes?<br>
> <br>
> <a href=3D"https://github.com/scipy/scipy/actions/runs/23708171067/job=
/69063440694?pr=3D24921" rel=3D"noreferrer" target=3D"_blank">https://githu=
b.com/scipy/scipy/actions/runs/23708171067/job/69063440694?pr=3D24921</a><b=
r>
> <br>
> Cheers,<br>
> Lucas<br>
> ________________________________<br>
> From: Sebastian Berg <<a href=3D"mailto:[email protected]"=
target=3D"_blank">[email protected]</a>><br>
> Sent: 29 March 2026 11:37<br>
> To: Discussion of Numerical Python <<a href=3D"mailto:numpy-discuss=
[email protected]" target=3D"_blank">[email protected]</a>><br>
> Subject: [Numpy-discussion] Deprecating unitless timedelta/datetime<br=
>
> <br>
> Hi all,<br>
> <br>
> I just merged a PR: <a href=3D"https://github.com/numpy/numpy/pull/296=
19" rel=3D"noreferrer" target=3D"_blank">https://github.com/numpy/numpy/pul=
l/29619</a><br>
> to deprecate unitless timdeldta/datetime64. This is a step in a<br>
> direction<br>
> that should be e.g. very helpful for pandas to make<br>
> timedelta/datetimes<br>
> less weird.<br>
> <br>
> That said, we didn't touch this for a long time, because it is als=
o<br>
> very hard to really understand how and if users might be impacted.<br>
> So if you notice this, or maybe even think you may be mixing<br>
> timedeltas<br>
> with normal integers/floats a lot you may want to try this branch.<br>
> <br>
> This is a `DeprecationWarning`, so it shouldn't out-right break co=
de<br>
> in<br>
> production.<br>
> <br>
> Note that there are also specific things we could try to make more<br>
> gentle, even something niche like specifically allowing:<br>
> `timdelta_arr =3D=3D 0` (although `timedelta_arr.astype(bool)` should =
be<br>
> a<br>
> plausible replacement as well, I think).<br>
> Or generally keep allowing `timedelta_arr + integer_arr`, etc. which,<=
br>
> with this PR, I believe should give a warning.<br>
> <br>
> Cheers,<br>
> <br>
> Sebastian<br>
> _______________________________________________<br>
> NumPy-Discussion mailing list -- <a href=3D"mailto:numpy-discussion@py=
thon.org" target=3D"_blank">[email protected]</a><br>
> To unsubscribe send an email to <a href=3D"mailto:numpy-discussion-lea=
[email protected]" target=3D"_blank">[email protected]</a><br>
> <a href=3D"https://mail.python.org/mailman3//lists/numpy-discussion.py=
thon.org" rel=3D"noreferrer" target=3D"_blank">https://mail.python.org/mail=
man3//lists/numpy-discussion.python.org</a><br>
> Member address: <a href=3D"mailto:[email protected]" target=3D"_=
blank">[email protected]</a><br>
> _______________________________________________<br>
> NumPy-Discussion mailing list -- <a href=3D"mailto:numpy-discussion@py=
thon.org" target=3D"_blank">[email protected]</a><br>
> To unsubscribe send an email to <a href=3D"mailto:numpy-discussion-lea=
[email protected]" target=3D"_blank">[email protected]</a><br>
> <a href=3D"https://mail.python.org/mailman3//lists/numpy-discussion.py=
thon.org" rel=3D"noreferrer" target=3D"_blank">https://mail.python.org/mail=
man3//lists/numpy-discussion.python.org</a><br>
> Member address: <a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a><br>
_______________________________________________<br>
NumPy-Discussion mailing list -- <a href=3D"mailto:numpy-discussion@python.=
org" target=3D"_blank">[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:numpy-discussion-leave@py=
thon.org" target=3D"_blank">[email protected]</a><br>
<a href=3D"https://mail.python.org/mailman3//lists/numpy-discussion.python.=
org" rel=3D"noreferrer" target=3D"_blank">https://mail.python.org/mailman3/=
/lists/numpy-discussion.python.org</a><br>
Member address: <a href=3D"mailto:[email protected]" target=3D"_blank">shoye=
[email protected]</a><br>
</blockquote></div></div>
--000000000000e1b6e4064e2d9d77--
--===============1210754223206558946==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
NumPy-Discussion mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3//lists/numpy-discussion.python.org
Member address: [email protected]
--===============1210754223206558946==--