BUG: `.dt.seconds` Discrepancy Between NumPy and PyArrow Timedelta Dtypes

[mattharrison]

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

import pandas as pd

duration = pd.Series(
    [pd.Timedelta(days=1, hours=2),
     pd.Timedelta(hours=5, minutes=30),
     pd.Timedelta(minutes=45, seconds=15)],
    index=['class_A', 'class_B', 'class_C']
)

# NumPy-backed
print(duration.dt.seconds)
# Output: [7200, 19800, 2715]

# PyArrow-backed
duration_arrow = duration.astype('duration[us][pyarrow]')
print(duration_arrow.dt.seconds)
# Output: [0, 0, 15]

Issue Description

There is a discrepancy in the behavior of the .dt.seconds accessor between pandas Series with NumPy-backed timedelta64[ns] dtype and PyArrow-backed duration[us][pyarrow] dtype.

Expected Behavior

Expected Behavior:
.dt.seconds should return the number of seconds (modulo 1 day) for both NumPy and PyArrow-backed timedeltas, matching the NumPy behavior.

Actual Behavior:
For PyArrow-backed timedeltas, .dt.seconds appears to modulo 1 minute seconds.

Installed Versions

Details

INSTALLED VERSIONS

commit : 1a3230d
python : 3.11.13
python-bits : 64
OS : Darwin
OS-release : 24.6.0
Version : Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:40 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6041
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : None
LOCALE : en_US.UTF-8

pandas : 3.0.0rc0
numpy : 2.2.6
dateutil : 2.9.0.post0
pip : None
Cython : 3.2.2
sphinx : None
IPython : 9.8.0
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.14.3
bottleneck : None
fastparquet : None
fsspec : None
html5lib : None
hypothesis : None
gcsfs : None
jinja2 : 3.1.6
lxml.etree : None
matplotlib : 3.10.7
numba : 0.62.1
numexpr : None
odfpy : None
openpyxl : None
psycopg2 : None
pymysql : None
pyarrow : 22.0.0
pyiceberg : None
pyreadstat : None
pytest : None
python-calamine : None
pytz : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlsxwriter : None
zstandard : None
qtpy : None
pyqt5 : None

[jorisvandenbossche]

It should indeed be the number of seconds below 1 day (https://pandas.pydata.org/docs/reference/api/pandas.Series.dt.seconds.html), that is the behaviour that is inherited from stdlib datetime.timedelta.

We also have a .dt.components that gives a more fine grained partitioning:

>>> duration.dt.components
         days  hours  minutes  seconds  milliseconds  microseconds  nanoseconds
class_A     1      2        0        0             0             0            0
class_B     0      5       30        0             0             0            0
class_C     0      0       45       15             0             0            0
>>> duration.dt.components.seconds
class_A     0
class_B     0
class_C    15
Name: seconds, dtype: int64

And indeed the pyarrow dtype gives the values equivalent to the seconds component.

[jorisvandenbossche]

Looking at the code and git history, this seems to have been introduced by #58052, to fix the dt.components behaviour of the pyarrow dtype.

@jbrockmendel actually mentioned the wrong behaviour the PR would introduce by changing .dt.seconds and not only .dt.components.seconds, but then the PR was merged regardless. @mroeschke @St0rmie introducing such inconsistency should maybe have been discussed a bit more?

[mroeschke]

I would be OK reverting #58052 for 3.0 then