Skip to content
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

Incorrect result with DateOffset.rollback for normalize=True #32616

Open
kdebrab opened this issue Mar 11, 2020 · 3 comments
Open

Incorrect result with DateOffset.rollback for normalize=True #32616

kdebrab opened this issue Mar 11, 2020 · 3 comments
Labels
Bug Frequency DateOffsets

Comments

@kdebrab
Copy link
Contributor

kdebrab commented Mar 11, 2020

Code Sample, a copy-pastable example if possible

from pandas.tseries.offsets import MonthBegin
MonthBegin(normalize=True).rollback('2020-4-1 12:34')
Out[2]: Timestamp('2020-03-01 00:00:00')

Problem description

It rollbacks to the beginning of the previous month instead of the current month. This happens only when normalize=True and the timestamp is within the first day of the month but strangely, it's correct for midnight:

from pandas.tseries.offsets import MonthBegin
MonthBegin(normalize=True).rollback('2020-4-1 00:00')
Out[3]: Timestamp('2020-04-01 00:00:00')

Expected Output

Out[2]: Timestamp('2020-04-01 00:00:00')

In general, I would expect the following to hold for any timestamp dt:

assert MonthBegin(normalize=True).rollback(dt) == MonthBegin().rollback(dt.normalize())

Output of pd.show_versions()

INSTALLED VERSIONS

commit : None
python : 3.6.8.final.0
python-bits : 64
OS : Windows
OS-release : 10
machine : AMD64
processor : Intel64 Family 6 Model 78 Stepping 3, GenuineIntel
byteorder : little
LC_ALL : None
LANG : None
LOCALE : None.None
pandas : 1.0.1
numpy : 1.18.1
pytz : 2019.3
dateutil : 2.8.1
pip : 20.0.2
setuptools : 40.6.2
Cython : 0.29.4
pytest : 5.3.5
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : 1.2.8
lxml.etree : 4.5.0
html5lib : 1.0.1
pymysql : None
psycopg2 : None
jinja2 : 2.11.1
IPython : 7.13.0
pandas_datareader: None
bs4 : 4.6.1
bottleneck : 1.3.1
fastparquet : None
gcsfs : None
lxml.etree : 4.5.0
matplotlib : 3.2.0
numexpr : 2.7.1
odfpy : None
openpyxl : 3.0.3
pandas_gbq : None
pyarrow : None
pytables : None
pytest : 5.3.5
pyxlsb : None
s3fs : 0.2.1
scipy : 1.4.1
sqlalchemy : 1.3.13
tables : None
tabulate : 0.8.6
xarray : 0.15.0
xlrd : 1.2.0
xlwt : 1.3.0
xlsxwriter : 1.2.8
numba : None

@kdebrab
Copy link
Contributor Author

kdebrab commented Mar 13, 2020

See also https://stackoverflow.com/a/56993025/1551810

@jbrockmendel jbrockmendel added the Frequency DateOffsets label Mar 27, 2020
@mroeschke mroeschke added the Bug label Jun 28, 2020
@ThomasA
Copy link

ThomasA commented Nov 1, 2023

I also experience this behaviour and it is also unexpected to me. Here more than 3 years later, sadly, the bug is still present in Pandas 2.1.2. Works as expected at midnight:

In [63]: ts = pd.Timestamp("2023-11-01 00:00:00", tz="UTC")

In [64]: pd.offsets.MonthBegin(normalize=True).rollback(ts)
Out[64]: Timestamp('2023-11-01 00:00:00+0000', tz='UTC')

In [65]: pd.offsets.MonthBegin().rollback(ts)
Out[65]: Timestamp('2023-11-01 00:00:00+0000', tz='UTC')

Unexpected behaviour at other times of the same day:

In [66]: ts = pd.Timestamp("2023-11-01 14:39:00", tz="UTC")

In [67]: pd.offsets.MonthBegin(normalize=True).rollback(ts)
Out[67]: Timestamp('2023-10-01 00:00:00+0000', tz='UTC')

In [68]: pd.offsets.MonthBegin().rollback(ts)
Out[68]: Timestamp('2023-11-01 14:39:00+0000', tz='UTC')

@zephyr707
Copy link

I just got bit by this bug and did not understand why normalize results in such unusual behaviour between midnight and a second after midnight. I am using Pandas 1.2.4, does the latest 2.1.3 fix this bug? Thanks to kdebrab for the stackoverflow link, looks like that is a solution to get around the bug.

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

No branches or pull requests

5 participants