Human here: @seberg as with my other recent PRs, acknowledging this is mostly claude. This is porting pandas-dev/pandas#65515

Claude below the line

Follow-up to GH-31378, which made datetime64/timedelta64 add, subtract, and integer-multiply raise OverflowError on int64 overflow instead of silently wrapping. This extends the same guarantee to the float multiply and divide loops, which previously cast the float64 result straight to int64 and silently saturated (or landed on the NaT sentinel) when the value exceeded int64 range.

What changes

TIMEDELTA_md_m_multiply (td * float), TIMEDELTA_dm_m_multiply (float * td), and TIMEDELTA_md_m_divide (td / float, which also backs td // float) now raise OverflowError when the result would overflow int64:

>>> np.timedelta64(2**62, "s") * 2.5      # was: silently wrapped
OverflowError: Overflow in timedelta64 * float64 multiplication
>>> np.timedelta64(2**62, "s") / 0.4      # was: silently wrapped
OverflowError: Overflow in timedelta64 / float64 division

A shared timedelta_from_double helper maps a NaN result to NaT and treats any magnitude >= 2**63 (finite overflow or ±inf) as overflow. The bound is 2**63 rather than int64.max, because 2**63 - 1 is not exactly representable in float64 and rounds up to 2**63; a result landing there would otherwise slip past the check and saturate on the cast (and -2**63 is itself the NaT sentinel).

Preserved (non-overflow) behavior

A NaN operand, 0 * inf, division by zero, and division by infinity still yield NaT (or zero), matching the pre-existing convention:

>>> np.timedelta64(5, "s") / 0.0          # NaT, not an error
>>> np.timedelta64(5, "s") / np.float64(np.inf)   # 0 seconds
>>> np.timedelta64(5, "s") * np.float64(np.nan)   # NaT

The one intentional behavior change to an existing test: timedelta64(nonzero) * inf now raises instead of returning NaT.

🤖 Generated with Claude Code