failures seem unrelated.
I'm uncertain if a new test is needed here. If the line is already covered (and I don't know that it is) you'd hit the deprecation warning sooner or later, and matplotlib is tested against numpy dev.

If the line is already covered (and I don't know that it is) you'd hit the deprecation warning sooner or later, and matplotlib is tested against numpy dev.

We have a regular Saturday task for testing against upstream nightly builds, so the laziest way to find out is to wait a couple of days.

lazy way it goes 😄
but ftr, we discovered this by testing astropy against matplotlib + numpy nightlies, so I know this line is affected but the deprecation warning.

I'm pretty wary about this change. Does NAT[s] return the same thing as NAT[ns] when converted to int64? I think it is a bit strange that numpy is wanting NaT to have a unit.

@jklymak sorry I accidentally edited your commit. - Reverted to the original.

Does NAT[s] return the same thing as NAT[ns] when converted to int64?

It currently does in 2.4.4. The question whether that's guaranteed behavior.

In [7]: np.timedelta64("NaT", 'ns') == np.timedelta64("NaT", "s")
Out[7]: np.False_

In [9]: np.timedelta64("NaT", 'ns').astype(np.int64) == np.timedelta64("NaT", "s").astype(np.int64)
Out[9]: np.True_
Otherwise, we'd have to create the right timedelta NaT.

Semi-related: We do this whole song-and-dance to create a boolean array marking the NaT entries in an datetime64 array. Isn't there a more straight forward solution for that?

Code path is coverd by test_date2num_NaT and test_date2num_NaT_scalar, so the fix is verified through CI.

@QuLogic Let's include this into 3.11 so that users won't run into the deprecation when numpy 2.5 comes out.