BUG: Creating an array with multiple NaTs can result in loss of NaTness

[WarrenWeckesser]

Describe the issue:

When two or more timedelta64 NaT instances with different units are used to create an array, it is possible for one of them to become a regular timedelta64 in the array.

Reproduce the code example:

In [48]: nat = np.timedelta64('nat')

In [49]: nat_s = np.timedelta64('nat', 's')

In [50]: nat_ms = np.timedelta64('nat', 'ms')

In [51]: a = np.array([nat, nat_s, nat_ms])

In [52]: a
Out[52]: array(['NaT',     0, 'NaT'], dtype='timedelta64[ms]')

In [53]: a[1]
Out[53]: np.timedelta64(0,'ms')  # This should be a NaT.

Python and NumPy Versions:

2.4.0.dev0+git20250801.9da497f
3.13.5 (main, Jul 15 2025, 14:50:34) [GCC 11.4.0]

Runtime Environment:

[{'numpy_version': '2.4.0.dev0+git20250801.9da497f',
'python': '3.13.5 (main, Jul 15 2025, 14:50:34) [GCC 11.4.0]',
'uname': uname_result(system='Linux', node='pop-os', release='6.12.10-76061203-generic', version='#202412060638175139074222.04~79b9668 SMP PREEMPT_DYNAMIC Tue J', machine='x86_64')},
{'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
'found': ['SSSE3',
'SSE41',
'POPCNT',
'SSE42',
'AVX',
'F16C',
'FMA3',
'AVX2'],
'not_found': ['AVX512F',
'AVX512CD',
'AVX512_KNL',
'AVX512_KNM',
'AVX512_SKX',
'AVX512_CLX',
'AVX512_CNL',
'AVX512_ICL']}},
{'architecture': 'Zen',
'filepath': '/usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so',
'internal_api': 'openblas',
'num_threads': 24,
'prefix': 'libopenblas',
'threading_layer': 'pthreads',
'user_api': 'blas',
'version': '0.3.20'}]

[WarrenWeckesser]

Another manifestation of the underlying problem is the following:

In [2]: x = np.zeros(5, dtype='m8[ms]')

In [3]: x[0] = np.timedelta64('nat', 's')

x[0] should be nat, but it is 0:

In [4]: x[0]
Out[4]: np.timedelta64(0,'ms')

The problem is in the C function cast_timedelta_to_timedelta(...):

numpy/numpy/_core/src/multiarray/datetime.c

Lines 3113 to 3150 in ae77211

	/*
	* Casts a single timedelta from having src_meta metadata into
	* dst_meta metadata.
	*
	* Returns 0 on success, -1 on failure.
	*/
	NPY_NO_EXPORT int
	cast_timedelta_to_timedelta(PyArray_DatetimeMetaData *src_meta,
	PyArray_DatetimeMetaData *dst_meta,
	npy_timedelta src_dt,
	npy_timedelta *dst_dt)
	{
	npy_int64 num = 0, denom = 0;
	/* If the metadata is the same, short-circuit the conversion */
	if (src_meta->base == dst_meta->base &&
	src_meta->num == dst_meta->num) {
	*dst_dt = src_dt;
	return 0;
	}
	/* Get the conversion factor */
	get_datetime_conversion_factor(src_meta, dst_meta, &num, &denom);
	if (num == 0) {
	return -1;
	}
	/* Apply the scaling */
	if (src_dt < 0) {
	*dst_dt = (src_dt * num - (denom - 1)) / denom;
	}
	else {
	*dst_dt = src_dt * num / denom;
	}
	return 0;
	}

It doesn't consider the case where src_dt is NPY_DATETIME_NAT. I'll submit a PR with a fix soon.