BUG: Addition/subtracting `pd.Timedelta` constructed from hour offset gives wrong results

[christianfosli]

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 datetime, timedelta, timezone

import pandas as pd

dt = datetime(2025, 9, 10, 23, 0, 0, tzinfo=timezone.utc)

print(dt - pd.Timedelta(hours=1))  # 2025-09-10 22:00:00+00:00
print(dt - pd.Timedelta(pd.tseries.offsets.Hour(1)))  # 2025-09-10 23:00:00+00:00


exp_result = datetime(2025, 9, 10, 22, 0, 0, tzinfo=timezone.utc)

assert dt - timedelta(hours=1) == exp_result  # works
assert dt - pd.Timedelta(hours=1) == exp_result  # works
assert pd.Timedelta(pd.tseries.offsets.Hour(1)) == timedelta(hours=1)  # works
assert dt - pd.Timedelta(pd.tseries.offsets.Hour(1)) == exp_result  # assertion error

Issue Description

Adding/subtracting pd.Timedelta constructed from an hour offset gives the wrong result.
It works as expected when constructing the pd.Timedelta object using e.g. pd.Timedelta(hours=1) instead of pd.Timedelta(pd.tseries.offsets.Hour(1)).

I initially noticed this constructing a pd.Timedelta from an datetimeindex freq, e.g. pd.Timedelta(df.index.freq)

Expected Behavior

Adding/subtracting pd.Timedelta should give the same results whether the timedelta is constructed from an hour offset or using hours={int}.

Installed Versions

INSTALLED VERSIONS

commit : 4665c10
python : 3.12.3
python-bits : 64
OS : Linux
OS-release : 6.14.0-29-generic
Version : #29~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Aug 14 16:52:50 UTC 2
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_GB.UTF-8
LOCALE : en_GB.UTF-8

pandas : 2.3.2
numpy : 2.3.2
pytz : 2025.2
dateutil : 2.9.0.post0
pip : None
Cython : None
sphinx : None
IPython : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : None
blosc : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : None
html5lib : None
hypothesis : None
gcsfs : None
jinja2 : None
lxml.etree : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
psycopg2 : None
pymysql : None
pyarrow : 21.0.0
pyreadstat : None
pytest : 8.4.1
python-calamine : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlsxwriter : None
zstandard : None
tzdata : 2025.2
qtpy : None
pyqt5 : None

[christianfosli]

Subtracting/adding offsets directly without converting to pd.Timedelta seems to work as expected.
So now I have my work-around 😄 But this still seems like a pretty clear bug IMO

print(dt - pd.tseries.offsets.Hour(1))  # 2025-09-10 22:00:00+00:00

[skalwaghe-56]

This exists on main.

[christianfosli]

This also works as expected

dt - pd.tseries.offsets.Hour(1).delta   # 2025-09-10 22:00:00+00:00
# FutureWarning: Hour.delta is deprecated and will be removed in a future version. Use pd.Timedelta(obj) instead

IIRC this deprecation warning is what made me try out pd.Timedelta(offset_obj) in the first place.

[skalwaghe-56]

take

[skalwaghe-56]

@jbrockmendel @rhshadrach @Aniketsy Your guidance will be really valuable.

I’ve been working on fixing this, and found that the core problem is Timedelta(Tick) not handling coarse-grained offsets like Hour/Minute/Second correctly. Casting them to ns resolves the bug.
However, if we cast all Tick objects to ns, existing tests break ('test_add_dt64_ndarray_non_nano') for finer-grained ticks (Milli, Micro, Nano), since they’re expected to preserve their natural resolution (ms, us, ns).
Should I Update the failing tests to expect the new consistent behavior?
Or should I Modify the fix to be more selective (only normalize Hour/Minute/Second, preserve ms/us/ns)?
Or something else?

[skalwaghe-56]

@rhshadrach Please let me know if any changes needs to be done in the PR.

[simonjayhawkins]

Thanks for the report @christianfosli

if you do

dt - pd.Timedelta(pd.tseries.offsets.BDay(1))

it fails with ValueError: Value must be Timedelta, string, integer, float, timedelta or convertible, not BusinessDay

Now, reading through #47845 the takeaways are:

1. Timedelta represents a fixed duration (e.g., 1 minute, 2 days), while Offset can encode calendar-aware logic (e.g., business days, month ends).

2. offsets and timedeltas are fundamentally different objects, even if they seem interchangeable to users.

So i think the first thing would be to check that our tests show we support (i.e. test) passing offsets to pd.Timedelta.

The bug could be that pd.Timedelta(pd.tseries.offsets.Hour(1))) should actually be raising?

accepting some offsets and not others could be a static typing nightmare.

[jbrockmendel]

It's not about the way the Timedelta is constructed. The problem is in datetime.datetime.__sub__ not handling timedelta subclasses correctly. Note that if you wrap dt in a Timestamp before operating, you get the correct result. xref #53643