BUG: Segfault constructing pd.Timedelta on Python 3.14 (pandas 3.0.4, regression from 3.0.3) #66086

Pandas version checks

• I have checked that this issue has not already been reported.
• I have confirmed this bug exists on the latest version of pandas.
• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

In a fresh virtualenv with only pandas==3.0.4 (and its required deps numpy, python-dateutil) installed on CPython 3.14:

import pandas as pd

pd.Timedelta(days=28)   # Fatal Python error: Segmentation fault

Any Timedelta constructor crashes the interpreter at construction time — pd.Timedelta(days=28), pd.Timedelta("28 days"), pd.Timedelta(28, "D"). No DataFrame/Series is involved, no threading, single-threaded python -c.

Issue Description

Constructing a pandas.Timedelta segfaults immediately on pandas 3.0.4 / CPython 3.14. This is a regression from 3.0.3 — in the same virtualenv, downgrading only pandas (3.0.4 → 3.0.3, numpy unchanged) makes the example work, and upgrading back to 3.0.4 crashes again. So pandas is the only changed variable.

It reproduces with numpy 2.3.3 (pandas 3.0.4's own declared minimum for Python 3.14, numpy>=2.3.3) and with numpy 2.4.6, so it is not specific to a single numpy build.

With PYTHONFAULTHANDLER=1, the C stack shows what looks like unbounded recursion between pandas/_libs/tslibs/timedeltas and numpy's _multiarray_umath, overflowing the C stack:

Current thread's C stack trace (most recent call first):
  ...python... _Py_DumpStack
  /lib/x86_64-linux-gnu/libc.so.6(+0x45330)
  numpy/_core/_multiarray_umath.cpython-314-x86_64-linux-gnu.so(+0x101f18)
  pandas/_libs/tslibs/timedeltas.cpython-314-x86_64-linux-gnu.so(+0x541ac)
  pandas/_libs/tslibs/timedeltas.cpython-314-x86_64-linux-gnu.so(+0x590ac)
  python _PyObject_MakeTpCall+0x1e7
  pandas/_libs/tslibs/timedeltas.cpython-314-x86_64-linux-gnu.so(+0x51f12)   # (deeper frames repeat the
  pandas/_libs/tslibs/timedeltas.cpython-314-x86_64-linux-gnu.so(+0x590ac)   #  timedeltas +0x590ac <-> MakeTpCall pattern)
  python _PyObject_MakeTpCall+0x1e7
  ...

The Python-level stack is just the single pd.Timedelta(...) call line — the fault is entirely in the compiled extension.

I haven't bisected which 3.0.4 commit introduced it, but the only _libs source change between 3.0.3 and 3.0.4 that touches this area is the datetime C code (e.g. the np_datetime.c include-order change, #65591/#65609); the maintainers will know best where to look.

Expected Behavior

pd.Timedelta(days=28) returns Timedelta('28 days 00:00:00'), as it does on pandas 3.0.3.

Note: this currently makes pandas 3.0.4 unusable for any downstream library that constructs a Timedelta at import time (e.g. importing RAPIDS cuDF segfaults for this reason).

I have only been able to test CPython 3.14.6 so far (couldn't easily build other interpreters in this environment); I don't yet know whether 3.11–3.13 are affected.

Installed Versions

INSTALLED VERSIONS
------------------
commit                : 8188eb1d65d6250c9916e54a0fa417d46af3296a
python                : 3.14.6
python-bits           : 64
OS                    : Linux
OS-release            : 6.14.0-37-generic
machine               : x86_64
processor             : x86_64
byteorder             : little
LANG                  : en_US.UTF-8
LOCALE                : en_US.UTF-8

pandas                : 3.0.4
numpy                 : 2.4.6   (also reproduced with numpy 2.3.3)
dateutil              : 2.9.0.post0
pip                   : 26.1.2