Since there is a specific code path for it, could we have a test that checks that the argmin is properly calculated when there is a bunch of leading 'NaT's followed by some actual data? Other than that, LGTM.

Given the change in behavior, perhaps it is worth a quick note in the release notes as well.

Funny... that uncovers a bug in np.min() as well:

>>> a = np.array([4, 'nat', 'nat', 2, 3], dtype='m8[s]')
>>> np.min(a)
numpy.timedelta64(2,'s')
>>> a = np.array(['nat', 'nat', 2, 3], dtype='m8[s]')
>>> np.min(a)
numpy.timedelta64('NaT','s')

Ok, I've pushed the changes. Should I squash the commits?

Can we really get rid of the specialized branch for binary reduces? I'd rather keep it, or at least have some timings supporting that the impact to performance is negligible.

Well, here are some runtimes before the patch:

>>> a = np.arange(1000).astype('m8[s]')
>>> %timeit np.min(a)
The slowest run took 41.48 times longer than the fastest. This could mean that an intermediate result is being cached 
100000 loops, best of 3: 5.49 µs per loop
>>> a[:a.size // 2] = np.timedelta64('nat', 's')
>>> %timeit np.min(a)
The slowest run took 10.66 times longer than the fastest. This could mean that an intermediate result is being cached 
100000 loops, best of 3: 5.51 µs per loop

And after:

>>> a = np.arange(1000).astype('m8[s]')
>>> %timeit np.min(a)
The slowest run took 13.43 times longer than the fastest. This could mean that an intermediate result is being cached 
100000 loops, best of 3: 6.72 µs per loop
>>> a[:a.size // 2] = np.timedelta64('nat', 's')
>>> %timeit np.min(a)
The slowest run took 10.43 times longer than the fastest. This could mean that an intermediate result is being cached 
100000 loops, best of 3: 5.72 µs per loop

20% slow down is not negligible, but correctness is sure worth at least that much. And it doesn't seem possible to do things "right" without manually expanding the BINARY_REDUCE_LOOP macro... I'm not 100% sure, but am leaning towards merging it as is.

@charris, @juliantaylor, anyone else: do you have a strong opinion about whether we should squeeze the last drop of performance out of minimum/maximum reduction, or are you OK with reusing the normal elementwise loop for this one case?

And it doesn't seem possible to do things "right" without manually expanding the BINARY_REDUCE_LOOP macro

It sounds like that to me as well.

That seems about enough waiting time, in it goes. Thanks Antoine!