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

BUG: register_matplotlib_converters leads to wrong datetime interpretation with matplotlib 3.3 #35350

Closed
2 of 3 tasks
ZahlGraf opened this issue Jul 20, 2020 · 7 comments · Fixed by #35393
Closed
2 of 3 tasks
Labels
Milestone

Comments

@ZahlGraf
Copy link

ZahlGraf commented Jul 20, 2020

  • 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.


Code Sample, a copy-pastable example

import datetime
import matplotlib
import matplotlib.pyplot as plt
from matplotlib.dates import DateFormatter

from pandas.plotting import register_matplotlib_converters
register_matplotlib_converters()

t = [
    datetime.datetime(2022, 12, 31, 0, 0), 
    datetime.datetime(2022, 11, 30, 0, 0), 
    datetime.datetime(2022, 10, 31, 0, 0),
]
s = [0.0, 0.1, 0.2]

fig, ax = plt.subplots()
ax.plot_date(x=t, y=s)
ax.xaxis.set_major_formatter(DateFormatter("%b '%y"))

plt.xticks(rotation=90)
plt.show()

Problem description

The years in the plot are now 91 and 92.

grafik

Note: With matplotlib 3.2.2 (the last stable release) the error is not there. So I guess this is a bug due to an api change inside matplotlib 3.3.0.

Expected Output

I expects the year 22 and 23 like in this image:

grafik

The second image can be produced by deleting the call to register_matplotlib_converters()

Output of pd.show_versions()

INSTALLED VERSIONS
------------------
commit           : None
python           : 3.7.6.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.5
numpy            : 1.19.0
pytz             : 2020.1
dateutil         : 2.8.1
pip              : 19.2.3
setuptools       : 41.2.0
Cython           : None
pytest           : None
hypothesis       : None
sphinx           : None
blosc            : None
feather          : None
xlsxwriter       : None
lxml.etree       : None
html5lib         : None
pymysql          : None
psycopg2         : None
jinja2           : None
IPython          : None
pandas_datareader: None
bs4              : None
bottleneck       : None
fastparquet      : None
gcsfs            : None
lxml.etree       : None
matplotlib       : 3.3.0
numexpr          : None
odfpy            : None
openpyxl         : None
pandas_gbq       : None
pyarrow          : None
pytables         : None
pytest           : None
pyxlsb           : None
s3fs             : None
scipy            : None
sqlalchemy       : None
tables           : None
tabulate         : None
xarray           : None
xlrd             : None
xlwt             : None
xlsxwriter       : None
numba            : None
@ZahlGraf ZahlGraf added Bug Needs Triage Issue that has not been reviewed by a pandas team member labels Jul 20, 2020
@TomAugspurger
Copy link
Contributor

@ZahlGraf do you see anything in the release notes that indicates what might have changed?

@ZahlGraf
Copy link
Author

Unfortunately not really. There are some changes to ticks, but they are not really related to dates:
https://matplotlib.org/3.3.0/users/whats_new.html

I also remember a deprecation warning about epoch2num, coming from pandas code. But there is already an issue for that (#34850) here and furthermore it is just a warning about upcoming changes.

@TomAugspurger TomAugspurger added Visualization plotting and removed Needs Triage Issue that has not been reviewed by a pandas team member labels Jul 20, 2020
@TomAugspurger
Copy link
Contributor

cc @jklymak on the hunch that this is related to the variable epoch changes in matplotlib/matplotlib#15008, but that's just a guess.

I'll hopefully have time to look more closely later in the week.

@jklymak
Copy link
Contributor

jklymak commented Jul 20, 2020

Yes our epoch changed from 0000-12-31T00:00:00 to 1970-01-01T00:00:00. You can check for the old behaviour via
plt.rcParams['date.epoch'] = '0000-12-31T00:00:00' and see if that fixes things.

@jklymak
Copy link
Contributor

jklymak commented Jul 20, 2020

I don't know why pandas relies on matplotlib's epoch - presumably you use mdates.date2num and its now incorrect. However, if at all possible its helpful to use a more modern epoch to give more resolution in floating point times.

@ZahlGraf
Copy link
Author

I can confirm, that using plt.rcParams['date.epoch'] = '0000-12-31T00:00:00' as a workaround fixes the issue.

import datetime
import matplotlib
import matplotlib.pyplot as plt
from matplotlib.dates import DateFormatter

from pandas.plotting import register_matplotlib_converters
register_matplotlib_converters()

plt.rcParams['date.epoch'] = '0000-12-31T00:00:00'

t = [
    datetime.datetime(2022, 12, 31, 0, 0), 
    datetime.datetime(2022, 11, 30, 0, 0), 
    datetime.datetime(2022, 10, 31, 0, 0),
]
s = [0.0, 0.1, 0.2]

fig, ax = plt.subplots()
ax.plot_date(x=t, y=s)
ax.xaxis.set_major_formatter(DateFormatter("%b '%y"))

plt.xticks(rotation=90)
plt.show()

@jklymak
Copy link
Contributor

jklymak commented Jul 20, 2020

Glad there is a workaround, and sorry for the inconvenience. I should have pinged pandas when the change went in. https://matplotlib.org/3.3.0/users/whats_new.html#dates-use-a-modern-epoch

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

Successfully merging a pull request may close this issue.

4 participants