BUG: Timedeltas less than 1 second truncate to 0

[cdholmes]

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

print( pd.Timedelta( 1, 's' ) / 2, "Result should be '0 days 00:00:00.500000'" )
print( pd.Timedelta( 1, 'day' ) * 0.1111, "Result should be '0 days 02:39:59.040000'" )
print( pd.Timedelta( 1, 'ms' ) * 2, "This works in 3.0. Result should be '0 days 00:00:00.002000'")
print( pd.Timedelta( 1, 'ms' ) / 2, "Result should be '0 days 00:00:00.000500'")

Issue Description

Timedeltas smaller than 1 second are truncated to 0 in some situations and larger Timedeltas are truncated to the nearest second. Similarly, dividing a 1 ms Timedelta by 2 is truncated to 0. This is distinct from the behavior reported in #65389, but they could be related.

This bug occurs in 3.0.3 and 3.0.2, but not in pandas 2.2.

import pandas as pd

print( pd.Timedelta( 1, 's' ) / 2, "Result should be '0 days 00:00:00.500000'" )
print( pd.Timedelta( 1, 'day' ) * 0.1111, "Result should be '0 days 02:39:59.040000'" )
print( pd.Timedelta( 1, 'ms' ) * 2, "This works in 3.0. Result should be '0 days 00:00:00.002000'")
print( pd.Timedelta( 1, 'ms' ) / 2, "Result should be '0 days 00:00:00.000500'")

Thanks for all the work that you do to make pandas so excellent!

Expected Behavior

The expected correct outputs are embedded in the code example. Dividing 1 second by 2 should give 0.5 second, not 0 second.

Installed Versions

Details

INSTALLED VERSIONS ------------------ commit : 72f2fea python : 3.14.4 python-bits : 64 OS : Darwin OS-release : 25.3.0 Version : Darwin Kernel Version 25.3.0: Wed Jan 28 20:56:35 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T6030 machine : arm64 processor : arm byteorder : little LC_ALL : None LANG : en_US.UTF-8 LOCALE : en_US.UTF-8

pandas : 3.0.3
numpy : 2.4.4
dateutil : 2.9.0.post0
pip : 26.0.1
Cython : None
sphinx : None
IPython : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : None
bottleneck : 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
psycopg2 : None
pymysql : None
pyarrow : None
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

[jbrockmendel]

Pls give your issue a helpful title

[jbrockmendel]

In pandas 3, pd.Timedelta(1, "s") and pd.Timedelta(1, "D") have .unit of "s", i.e. they are stored natively as seconds. The division is correct in rounding down to zero. To get the result you're looking for you'll need to convert to a finer unit e.g. td.as_unit("ms")

[cdholmes]

Thank you for the explanation. I think that is a sensible default, but I couldn't find that in the documentation. The Timedelta API docs says the default unit is 'ns': "unit : str, default ‘ns’". A mention in the Release Notes might also help.

As far as I'm concerned, please feel free to close this issue.

[jbrockmendel]

A PR improving the docs would be welcome.

[Parth-Dholariya]

Thank you for the explanation. It sounds like a good idea to work on improving the documentation here.

My proposed changes are to add the information in Timedelta's documentation stating that Timedeltas can retain their underlying resolution/unit in pandas 3 and, therefore, operations such as pd.Timedelta(1, "s") / 2 can be subject to rounding based on the units used. I'll also include an example to show how users can use .as_unit("ms"), .as_unit("us"), and .as_unit("ns") prior to performing operations where finer resolution is required.

Does that seem appropriate for the task at hand?