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 <[email protected]> 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=24921 > > > > 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 == 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 -- [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] >
_______________________________________________ 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]
