Timedelta error:one month NOT exactly

[princelai]

Code Sample, a copy-pastable example if possible

pd.Timedelta(1,unit='M')
Out[119]: Timedelta('30 days 10:29:06')

pd.Timedelta(2,unit='M')
Out[120]: Timedelta('60 days 20:58:12')

pd.Timedelta(1,unit='d')
Out[121]: Timedelta('1 days 00:00:00')

Problem description

only month has problem.
day and week works #fine.
pandas version 0.19 yield right result ,but 0.20+ goes wrong

Expected Output

Output of pd.show_versions()

pd.show_versions()

INSTALLED VERSIONS

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

pandas: 0.20.1
pytest: 3.0.7
pip: 9.0.1
setuptools: 35.0.1
Cython: 0.25.2
numpy: 1.12.1
scipy: 0.19.0
xarray: None
IPython: 6.0.0
sphinx: 1.5.5
patsy: 0.4.1
dateutil: 2.6.0
pytz: 2017.2
blosc: None
bottleneck: 1.2.0
tables: 3.2.2
numexpr: 2.6.2
feather: None
matplotlib: 2.0.1
openpyxl: 2.4.1
xlrd: 1.0.0
xlwt: 1.2.0
xlsxwriter: 0.9.6
lxml: 3.7.3
bs4: 4.5.3
html5lib: 0.999999999
sqlalchemy: 1.1.9
pymysql: 0.7.11.None
psycopg2: None
jinja2: 2.9.6
s3fs: None
pandas_gbq: None
pandas_datareader: None

[jorisvandenbossche]

Can you show the output that you think is correct for pandas 0.19 ?

I get a consistent (but maybe wrong, that could be discussed) output for the latest releases:

In [52]: pd.__version__
Out[52]: '0.21.0.dev+19.g69a5d6f.dirty'

In [53]: pd.Timedelta(1, unit='M')
Out[53]: Timedelta('30 days 10:29:06')

In [2]: pd.__version__
Out[2]: '0.19.2'

In [3]: pd.Timedelta(1, unit='M')
Out[3]: Timedelta('30 days 10:29:06')

In [1]: pd.__version__
Out[1]: u'0.18.1'

In [2]: pd.Timedelta(1, unit='M')
Out[2]: Timedelta('30 days 10:29:06')

That said, I think we should actually disallow the M unit, as this does not make sense. Timedelta is made for fixed intervals (with a fixed length), not for relative / variable length periods (which a 'month' is, in constrast with eg a 'day')

[jreback]

xref to #12691

this was for numpy compat. I agree, let's deprecate passing 'M', 'Y' on construction (see also the xref #12691 where they are passed as strings).