Skip to content

Pandas TimeDelta instantiation returns different object for same value #25544

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Dgomzi opened this issue Mar 5, 2019 · 6 comments
Closed

Pandas TimeDelta instantiation returns different object for same value #25544

Dgomzi opened this issue Mar 5, 2019 · 6 comments
Labels
Bug Timedelta Timedelta data type

Comments

@Dgomzi
Copy link

Dgomzi commented Mar 5, 2019

pd.Timedelta(3,unit= 'M')
Out[26]: Timedelta('91 days 07:27:18')
pd.Timedelta('3M')
Out[27]: Timedelta('0 days 00:03:00')

Problem description

I tried instantiating Timedelta object using '3M' which returns Timedelta object with 3 minutes rather than 3Months

Output of pd.show_versions()

INSTALLED VERSIONS

commit: None
python: 3.6.2.final.0
python-bits: 32
OS: Windows
OS-release: 10
machine: AMD64
processor: Intel64 Family 6 Model 78 Stepping 3, GenuineIntel
byteorder: little
LC_ALL: None
LANG: None
LOCALE: English_United States.1252
pandas: 0.24.1
pytest: None
pip: 10.0.1
setuptools: 39.1.0
Cython: None
numpy: 1.16.1
scipy: 1.2.1
pyarrow: None
xarray: None
IPython: 7.3.0
sphinx: 1.8.4
patsy: 0.5.1
dateutil: 2.8.0
pytz: 2018.9
blosc: None
bottleneck: None
tables: None
numexpr: None
feather: None
matplotlib: 3.0.2
openpyxl: None
xlrd: None

@WillAyd
Copy link
Member

WillAyd commented Mar 5, 2019

Hmm I can see the confusion here. I think just a bug with the parser maybe not expecting months to be a valid identifier, though certainly should given the ISO 8601 spec.

Investigation and PRs would certainly be welcome. cc @mroeschke

@WillAyd WillAyd added Bug Timedelta Timedelta data type labels Mar 5, 2019
@WillAyd WillAyd added this to the Contributions Welcome milestone Mar 5, 2019
@TomAugspurger
Copy link
Contributor

It should raise right? Since 3 months can't be represented as a fixed span of time?

@WillAyd
Copy link
Member

WillAyd commented Mar 5, 2019

Also a good question. It's valid per the ISO 8601 spec:

https://en.wikipedia.org/wiki/ISO_8601#Durations

Though perhaps that would cause some issues with Python's time delta given it only stores up to days, so seems like it could be ambiguous the span of time we want to represent here. Not entirely sure myself...

@WillAyd WillAyd added Needs Discussion Requires discussion from core team before further action and removed Bug labels Mar 5, 2019
@TomAugspurger
Copy link
Contributor

This came up with JSON table schema too. It wasn't clear to me then that timedeltas were equivalent to durations. I don't think you can say that "P3M" is iso-8601-duration notation is equivalent "n seconds" where n is the .value of our timedelta.

@mroeschke
Copy link
Member

We just deprecated the ability to pass M (month) and Y (year) as units because of the fixed span of time issue @TomAugspurger mentioned. #23264

The behavior of pd.Timedelta('3M') might have been changed recently in #23439, but since we are deprecating M, it might be a bug that we expect to go away with the deprecation.

@mroeschke mroeschke added Bug and removed Needs Discussion Requires discussion from core team before further action labels May 3, 2020
@mroeschke
Copy link
Member

Going to close this issue as it looks like a duplicate of #27285 with more examples

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Timedelta Timedelta data type
Projects
None yet
Development

No branches or pull requests

4 participants