BUG: `TimedeltaIndex` and `Index[timedelta]` behave differently upon `__rtruediv__`

[cmp0xff]

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

from datetime import timedelta
from typing import reveal_type
import pandas as pd

timedeltaindex = pd.Index([pd.Timedelta(seconds=1)]) * [1]
reveal_type(timedeltaindex)  # TimedeltaIndex, contains pd.Timedelta
reveal_type(timedelta(seconds=1) / timedeltaindex)  # Index, no error

index_timedelta = pd.Index([1]) * [pd.Timedelta(seconds=1)]
reveal_type(index_timedelta)  # Index, contains datetime.timedelta
reveal_type(timedelta(seconds=1) / index_timedelta)  # error

Issue Description

In #62524 I've shown that Index[timedelta] instead of TimedeltaIndex can be produced.

Here I found that these objects behave differently when rtruedived by another timedelta.

Expected Behavior

Consistently giving Index[float]

Installed Versions

INSTALLED VERSIONS

commit : 4665c10
python : 3.12.10
python-bits : 64
OS : Windows
OS-release : 11
Version : 10.0.26100
machine : AMD64
processor : AMD64 Family 25 Model 116 Stepping 1, AuthenticAMD
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : Czech_Czechia.1252

pandas : 2.3.2
numpy : 2.3.4
pytz : 2025.2
dateutil : 2.9.0.post0
pip : 24.2
Cython : None
sphinx : None
IPython : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.14.2
blosc : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : None
html5lib : 1.1
hypothesis : None
gcsfs : None
jinja2 : 3.1.6
lxml.etree : 6.0.2
matplotlib : 3.10.6
numba : None
numexpr : 2.13.1
odfpy : None
openpyxl : 3.1.5
pandas_gbq : None
psycopg2 : None
pymysql : None
pyarrow : 21.0.0
pyreadstat : 1.3.1
pytest : 8.4.2
python-calamine : None
pyxlsb : 1.0.10
s3fs : None
scipy : 1.16.2
sqlalchemy : 2.0.43
tables : 3.10.2
tabulate : 0.9.0
xarray : 2025.9.1
xlrd : 2.0.2
xlsxwriter : 3.2.9
zstandard : None
tzdata : 2025.2
qtpy : None
pyqt5 : None

[jbrockmendel]

is the complaint about the behavior of Index[object].__rtruediv__ or about pd.Index([1]) * [pd.Timedelta(seconds=1)] having object dtype?

[cmp0xff]

• pd.Index([1]) * [pd.Timedelta(seconds=1)] having object dtype is the topic in BUG: Inconsistent runtime typing for Index[num] * list[timestamp] #62524, not here
• Here I am reporting Index[timestamp].__rtruediv__

[rhshadrach]

We convert to NumPy timedelta64 when performing this operation. I'm wondering if this is a NumPy issue. I would expect object dtype to try to preform the division elementwise, but it seems NumPy has special cased these dtypes.

from datetime import timedelta
import numpy as np

arr = np.array([timedelta(seconds=1)], dtype="object")
scalar = np.timedelta64(1, 's')

print(arr[0] / scalar)
# 1.0

print(arr / 2)
# [datetime.timedelta(microseconds=500000)]

print(arr / scalar)
# numpy._core._exceptions._UFuncBinaryResolutionError: ufunc 'divide' cannot use operands with types dtype('O') and dtype('<m8[s]')

[jbrockmendel]

i suspect a fix is possible in Timedelta.__truediv__

[rhshadrach]

No objection to working around this on our end. Reported in numpy/numpy#30025, @seberg mentioned offline he believes this can be fixed in NumPy.

[rhshadrach]

Using the main branch of NumPy, I now get Index([1.0], dtype='object') for the last line in the OP as expected.

@jbrockmendel - would you still want a patch for earlier versions of NumPy?

[jbrockmendel]

I wouldn’t bother, but wouldn’t complain if someone wanted to implement it