Conversation
NaT is stored as the minimum int64 value, and casts to floating-point types used that value as is, giving -9.2e18. For float16 the value is out of range, so the cast gave -inf along with an overflow warning. The reverse cast already maps NaN to NaT. To match it, map NaT to NaN. For complex types, the real part is NaN and the imaginary part is 0. Casts to integer types and bool are unchanged. Integer types have no equivalent of NaN, and for int64 NaT stays the minimum value, so casting back to datetime gives NaT again. For bool, NaT is true, the same as NaN. Closes numpy#26177
Hee-San
marked this pull request as ready for review
September 24, 2026 12:47
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR summary
Closes #26177
This PR changes the casting of
np.datetime64('NaT')andnp.timedelta64('NaT')to floating-point and complex types so thatNaTis converted toNaN.Internally,
NaTis stored as the minimumint64value, so casting to afloattype used that value as-is, producing-9.2e18. Forfloat16, the value is out of range, so it became-infalong with an overflow warning.With this change,
NaTis now converted toNaNwithout any warning.Before the fix (numpy 2.5.3):
After the fix (local build of
mainwith this patch applied):Casting to integer and bool types is unchanged.
Integer types have no equivalent of
NaN, and withint64theNaTsentinel is preserved as the minimum value, so the existing behavior already round-trips back toNaTwhen cast back to a datetime type.For bool,
NaTevaluates toTrue, just likeNaNdoes.Same output before and after the fix:
First time contributor introduction
Back in my student days (up until about five years ago), I used NumPy for studying and doing research in computer science and the sciences.
I now work as a software engineer, and I don't get to use NumPy in my day job.
Still, I'd like to give back to the various open-source projects I've benefited from over the years by contributing to them.
I picked a long-standing issue that had no PR yet and that I felt I could handle even though I don't use NumPy much these days.
AI Disclosure
Tool used: Anthropic's Claude Code.
Investigation: I used it to identify which conversion functions the cast goes through, to confirm the reproduction, and to understand the surrounding related functions.
Code: The C changes and the tests were generated by the AI. I then had it explain the code to me line by line so I understood it, and I directed it to revise the tests in terms of how they are written and what they cover — specifically how the functions are split up, matching the style of the existing tests, and where comments are placed. I judged the AI-written code for the fix itself to be fine as-is, so I adopted it unchanged. The AI also ran the build and the tests.
Writing: The issue comments, the commit messages, and this PR description were written by me in Japanese and simple English, then translated and polished by the AI.
I apologize for PR #32775, where I opened a draft PR that didn't follow the template.
That PR was created by me manually, not submitted automatically by an AI agent.