Skip to content

Timestamp ceil rounds up when it should not when using the '15min' frequency in 0.23.0. #21262

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
Safrone opened this issue May 30, 2018 · 5 comments
Labels
Bug Datetime Datetime data dtype Regression Functionality that used to work in a prior pandas version
Milestone

Comments

@Safrone
Copy link

Safrone commented May 30, 2018

Code Sample

>>> import pandas as pd
>>> pd.Timestamp('2018-01-12 18:15:00').ceil('15T')
Timestamp('2018-01-12 18:30:00')

>>> pd.Timestamp('2018-01-12 00:30:00').ceil('15T')
Timestamp('2018-01-12 00:45:00')

Problem description

When the frequency is 15min .ceil() rounds up when the timestamp is divisible by the frequency.

From some experimentation, this also occurs with some other minute frequencies, notably: 2, 4, 15, 20

Minute frequencies that are factors of 60 should have consistent behavior in my opinion (not sure about the behavior of non-factors but those would be rare edge cases).

This appears to be a regression in the latest version of pandas 0.23.0 as it is working as expected in 0.22.0

Expected Output

>>> pd.Timestamp('2018-01-12 18:15:00').ceil('15T')
Timestamp('2018-01-12 18:15:00')

>>> pd.Timestamp('2018-01-12 00:30:00').ceil('15T')
Timestamp('2018-01-12 00:30:00')

Output of pd.show_versions()

INSTALLED VERSIONS

commit: None
python: 3.5.1.final.0
python-bits: 64
OS: Linux
OS-release: 4.4.0-124-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: en_US.UTF-8

pandas: 0.23.0
pytest: 2.8.5
pip: 9.0.1
setuptools: 39.2.0
Cython: 0.23.4
numpy: 1.14.3
scipy: 0.17.1
pyarrow: None
xarray: None
IPython: 6.4.0
sphinx: 1.3.1
patsy: 0.4.1
dateutil: 2.7.3
pytz: 2018.4
blosc: None
bottleneck: 1.0.0
tables: 3.2.2
numexpr: 2.5.2
feather: None
matplotlib: 1.5.1
openpyxl: 2.3.2
xlrd: 0.9.4
xlwt: 1.0.0
xlsxwriter: 0.8.4
lxml: 3.6.0
bs4: 4.4.1
html5lib: None
sqlalchemy: 1.0.12
pymysql: None
psycopg2: 2.6.2 (dt dec pq3 ext lo64)
jinja2: 2.8
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None

@uds5501
Copy link
Contributor

uds5501 commented May 30, 2018

I am sorry but I can't recreate your error in my system, It's working like it should
image

@Safrone
Copy link
Author

Safrone commented May 30, 2018

@uds5501 What version of pandas are you using? This happened to me on the latest pandas 0.23.0. I tested on an older version of pandas (0.22.0) and it worked as you showed.

@Safrone Safrone changed the title Timestamp ceil rounds up when it should not when using the '15min' frequency. Timestamp ceil rounds up when it should not when using the '15min' frequency in 0.23.0. May 30, 2018
@Safrone
Copy link
Author

Safrone commented May 30, 2018

i created a PR with tests that fail showing this issue ^

@jschendel
Copy link
Member

Yes, this is occurring on master:

In [2]: pd.__version__
Out[2]: '0.24.0.dev0+43.g4cbbcc6'

In [3]: pd.Timestamp('2018-01-12 18:15:00').ceil('15T')
Out[3]: Timestamp('2018-01-12 18:30:00')

In [4]: pd.Timestamp('2018-01-12 00:30:00').ceil('15T')
Out[4]: Timestamp('2018-01-12 00:45:00')

I suspect this was introduced in #19240

@jschendel jschendel added Bug Datetime Datetime data dtype Regression Functionality that used to work in a prior pandas version labels May 30, 2018
@jreback jreback added this to the 0.23.1 milestone May 31, 2018
@jreback jreback modified the milestones: 0.23.1, 0.23.2 Jun 7, 2018
@alimcmaster1
Copy link
Member

Currently looking into this. Thanks @jschendel that PR you linked was very useful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Datetime Datetime data dtype Regression Functionality that used to work in a prior pandas version
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants