BUG: to_timedelta() works differently depending on type of arg for the same unit

[deepster5150]

• [X ] I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

Note: Please read this guide detailing how to provide the necessary information for us to reproduce your bug.

Code Sample, a copy-pastable example

# Your code here
<Timestamp object> += pd.to_timedelta(16, unit='hours') , OR
<Timestamp object> += pd.to_timedelta("16", unit='hours')

Problem description

+= pd.to_timedelta(16, unit='hours') will add correctly to hours
+= pd.to_timedelta("16", unit='hours') will add to milliseconds

As per documentation, arg=string should work for the specified unit.

Expected Output

opt_expiry_dt += pd.to_timedelta("16", unit='hours'), gives:
2020-06-12 00:00:00.000000016

opt_expiry_dt += pd.to_timedelta(16, unit='hours'), gives:
2020-06-19 16:00:00

Output of pd.show_versions()

INSTALLED VERSIONS ------------------ commit : None python : 3.7.4.final.0 python-bits : 64 OS : Windows OS-release : 10 machine : AMD64 processor : Intel64 Family 6 Model 94 Stepping 3, GenuineIntel byteorder : little LC_ALL : None LANG : None LOCALE : None.None

pandas : 0.25.1
numpy : 1.16.5
pytz : 2019.3
dateutil : 2.8.0
pip : 19.2.3
setuptools : 41.4.0
Cython : 0.29.13
pytest : 5.2.1
hypothesis : None
sphinx : 2.2.0
blosc : None
feather : None
xlsxwriter : 1.2.1
lxml.etree : 4.4.1
html5lib : 1.0.1
pymysql : None
psycopg2 : None
jinja2 : 2.10.3
IPython : 7.8.0
pandas_datareader: None
bs4 : 4.8.0
bottleneck : 1.2.1
fastparquet : None
gcsfs : None
lxml.etree : 4.4.1
matplotlib : 3.1.1
numexpr : 2.7.0
odfpy : None
openpyxl : 3.0.0
pandas_gbq : None
pyarrow : None
pytables : None
s3fs : None
scipy : 1.3.1
sqlalchemy : 1.3.9
tables : 3.5.2
xarray : None
xlrd : 1.2.0
xlwt : 1.3.0
xlsxwriter : 1.2.1

[miccoli]

By inspecting the source code, it appears that this is intended behaviour: the unit argument is used only for numeric input and ignored for strings. String parsing is very complex (impossible to summarise here) but for numeric literals like '1' or '16' a default unit of 'ns' is assumed.

Simple examples:

>>> pd.to_timedelta([1, 0.1, 0.01], unit='hours')
TimedeltaIndex(['01:00:00', '00:06:00', '00:00:36'], dtype='timedelta64[ns]', freq=None)
>>> pd.to_timedelta(['1h', '1m', '1s'])
TimedeltaIndex(['01:00:00', '00:01:00', '00:00:01'], dtype='timedelta64[ns]', freq=None)

On the contrary in the following

>>> pd.to_timedelta(['1h', '1m', '1s'], unit='hours')
TimedeltaIndex(['01:00:00', '00:01:00', '00:00:01'], dtype='timedelta64[ns]', freq=None)

the unit='hours' argument is simply ignored.

But please note also this valid example, where numbers and strings are mixed

>>> pd.to_timedelta(['1m', 1], unit='hours')
TimedeltaIndex(['00:01:00', '01:00:00'], dtype='timedelta64[ns]', freq=None)

Therefore the current behaviour is, although not well documented, consistent.

In my opinion there are a few options here.

1. Clarify the documentation and label this issue as 'documentation'.
2. Use the unit argument as the default for strings without explicit units.
3. Raise a warning if an explicit unit argument is used with input strings.

It seems to me that the first option is the more sensible one. The source code is quite complex, with different paths, so changing the current behaviour in a backward compatible way could be very difficult.

[matteo-pallini]

I had the same problem and I was going to create an issue.

As a user I would find more useful if a warning (or an error) was raised in this case. As a consumer of the API I am expecting the arguments that I am passing to the function to be used. If it's not the case becuase the combination of them is not feasible I am expecting the library to let me about it. Doing something different without letting me know is not a gret user experience I would say. Not everyone reads the documents super-throughly before using some function.

[TAJD]

take