You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
3.3.0: possible regression/bug with DateFormatter? #18010
Hello,
i have this code that worked fine until mpl 3.3.0; now if you run it, it generate this image - notice the X axes tick labels, 3989? that's supposed to be 2020 :) (for comparison you can look at last month image )
Is there anything wrong with that code i was using or is there a bug/regression in mpl?
thanks!
Reacted by David Cottrell, Sebastian Veuskens and Numeric Lee
Even if I change plt.rcParams['date.epoch'] = '1970-01-01T00:00:00' or plt.rcParams['date.epoch'] = '0000-12-31T00:00:00' I get the same image. So this is a bit of a mystery as to why its not working for you.
from your ipython shell does it still give the strange dates? EDIT: they're not strange, they are just 1970 years too far in the future. ie the datenum is coming out as one that has the old epoch, but then getting converted back using the new one.
BTW, not sure if discord would help, and this is fine for tracking the issue. OTOH, I'm not sure what else I can do. It'd be good if you could reproduce on a fresh env. If I do conda create -n boo matplotlib numpy and conda activate boo I get the same results. So I'm pretty mystified.
That is strange - seems like a crossed-up install, but not sure I understand why. I guess you could put the print statements above into a script and run from the command line.
ok, it looks like i may have had to pay more attention to the message on the console:
/usr/lib/python3/dist-packages/pandas/plotting/_matplotlib/converter.py:103: FutureWarning: Using an implicitly registered datetime converter for a matplotlib plotting method. The converter was registered by pandas on import. Future versions of pandas will require you to explicitly register matplotlib converters.
To register the converters:
>>> from pandas.plotting import register_matplotlib_converters
>>> register_matplotlib_converters()
warnings.warn(msg, FutureWarning)
/usr/lib/python3/dist-packages/pandas/plotting/_matplotlib/converter.py:245: MatplotlibDeprecationWarning:
The epoch2num function was deprecated in Matplotlib 3.3 and will be removed two minor releases later.
base = dates.epoch2num(dt.asi8 / 1.0e9)
that's produced when executing the script on console: is this our smoking gun?
Yes; Epoch2num was not updated to the new epoch. So this will be closed by a PR from yesterday. But I still don't 100% understand because you are explicitly using matplotlib's formatter.
lemme apply that patch (hoping it applies cleanly on top of 3.3.0) to the debian package and re-try; will update as soon as the build process finishes so... not very soon :)
yep that was it: with that PR applied on top of 3.3.0, the script now works fine. i'm gonna upload the fix to Debian, but I agree a .1 with that patch released officially would be ideal -- thanks for debugging this with me!
Activity
jklymak commentedon Jul 22, 2020
https://matplotlib.org/3.3.0/users/whats_new.html#dates-use-a-modern-epoch
But I don't understand why your dates, which seem to be just
datetimeobjects, are not just working.jklymak commentedon Jul 22, 2020
I cannot reproduce this on master or v.3.3.0.
I get:
Even if I change
plt.rcParams['date.epoch'] = '1970-01-01T00:00:00'orplt.rcParams['date.epoch'] = '0000-12-31T00:00:00'I get the same image. So this is a bit of a mystery as to why its not working for you.jklymak commentedon Jul 22, 2020
If you do
and report the results, that would be useful. For me I get
sandrotosi commentedon Jul 22, 2020
yep, same:
sandrotosi commentedon Jul 22, 2020
could be some outdated rcparams?
jklymak commentedon Jul 22, 2020
The relevant new rcParam is
date.epochand its correct.Is it something funny in your env? What happens if you simplify this to:
from your ipython shell does it still give the strange dates? EDIT: they're not strange, they are just 1970 years too far in the future. ie the datenum is coming out as one that has the old epoch, but then getting converted back using the new one.
jklymak commentedon Jul 22, 2020
Also can't hurt to make sure this roundtrips:
sandrotosi commentedon Jul 22, 2020
i tried your code and i get the weird dates

sandrotosi commentedon Jul 22, 2020
sandrotosi commentedon Jul 22, 2020
(if you prefer a different way to debug this, like maybe on discord or smth, just let me know :) )
jklymak commentedon Jul 22, 2020
Gives me
2020...jklymak commentedon Jul 22, 2020
BTW, not sure if discord would help, and this is fine for tracking the issue. OTOH, I'm not sure what else I can do. It'd be good if you could reproduce on a fresh env. If I do
conda create -n boo matplotlib numpyandconda activate booI get the same results. So I'm pretty mystified.2 remaining items
sandrotosi commentedon Jul 22, 2020
weirder and weirder: if i restart ipython, i get the right dates too! but i run the original script from the command-line, still 3989 ....
jklymak commentedon Jul 22, 2020
That is strange - seems like a crossed-up install, but not sure I understand why. I guess you could put the print statements above into a script and run from the command line.
sandrotosi commentedon Jul 22, 2020
sandrotosi commentedon Jul 22, 2020
ok, it looks like i may have had to pay more attention to the message on the console:
that's produced when executing the script on console: is this our smoking gun?
jklymak commentedon Jul 22, 2020
Yes; Epoch2num was not updated to the new epoch. So this will be closed by a PR from yesterday. But I still don't 100% understand because you are explicitly using matplotlib's formatter.
jklymak commentedon Jul 22, 2020
@sandrotosi so was one of your pandas pre 1.0.0?
I think all this speaks to getting #17983 in a release as soon as possible to address this conflict, at least for folks using older pandas. See also pandas-dev/pandas#35350, pandas-dev/pandas#34850, and pandas-dev/pandas#35361
sandrotosi commentedon Jul 23, 2020
yes, on my system i have pandas/0.25.3 while there is no pandas installed in the container
lemme apply that patch (hoping it applies cleanly on top of 3.3.0) to the debian package and re-try; will update as soon as the build process finishes so... not very soon :)
sandrotosi commentedon Jul 23, 2020
yep that was it: with that PR applied on top of 3.3.0, the script now works fine. i'm gonna upload the fix to Debian, but I agree a .1 with that patch released officially would be ideal -- thanks for debugging this with me!
cottrell commentedon Jul 24, 2020
Can someone unpack this thread? What is the final outcome as it stands?
cottrell commentedon Jul 24, 2020
tldr; for those landing here. Using matplotlib master fixes this.
pprayoga commentedon Jul 24, 2020
might want to check this https://stackoverflow.com/questions/63078267/x-axis-in-matplotlib-print-random-numbers-instead-of-the-years/63079594#63079594
QuLogic commentedon Jul 24, 2020
Closing, as this will be fixed in 3.3.1.
jklymak commentedon Jul 24, 2020
Just for posterity sake, the workaround is to manually specify the old pre-3.3.0 epoch in your script.
plt.rcParams['date.epoch'] = '0000-12-31T00:00'