wow, that's a doozy. does this still happen in 2.0b4 with mpl.use('classic')? If so, then that image could be use for direct comparison with the 1.5 image to figure out the exact differences (did the y-spine or the x-spine shift?)
You can't tell if it is an x or y spine shift to the right or left just by looking at one image. It has to be compared to a baseline - hence why classic mode would be helpful here since fonts and other settings have changed that would complicate direct comparisons.
We have to convert to float at some point. That involves an inherent loss in resolution over a given date range.
As pointed out numerous times, using matplotlib date plotting on timescales shorter than milliseconds will lead to inaccuracies and the user should just plot as seconds from the start of the day, or some other reference time. I really don’t think there is any advantage to specially handling dates at such a small scale.
I'm actually fine with saying "we can't do anything about it", but I think if we can't even position plot elements accurately (if spines are at the wrong place it seems likely that other artists will be rendered at the wrong place too) then we should just error out. Or at least reword the warning in #15000 to something stronger: it's not that plotting microseconds at current reference times is "not well supported", it's that the plot may well have nothing to do with your actual data.
That'd be fine. But we don't error out on other floating point inaccuracies, its just that this one is more unexpected.
One thing we could do is change the epoch to something more modern, like 1970, or 2000. Most people plotting old dates do not need millisecond accuracy.
OK, what do you think about an mdates.set_epoch('1970-01-01') or some such? That would allow users who want to set today as the epoch get resolution out to very small numbers. Of course you would need to set the epoch before you start plotting, but that doesn't seem to be an issue to me.
I guess that may be nice to have.
OTOH your comment about other floating point inaccuracies not being warned upon also convinced me that this may not be worth overthinking about.
I did it. It works, down the point the microsecond locator gives up. But... we lose some guard-rails, like matplotlib times can't be less than 1. OTOH, not sure why that's really needed or desirable.
I guess I'm still somewhat of the opinion that if you are going to go to the trouble of specifying an epoch, you might as well just subtract the epoch from the time and plot as floats yourself, but I could be convinced otherwise.
Well we can still say "put your epoch to somewhere earlier than any date you're planning to use" and call it a day. We can even make date2num and friends set a global variable "a date conversion has been done" and make set_epoch error out if any date conversion has already been done (so that we don't end up with inconsistent epochs).
However I certainly also agree we may be overengineering this.
Activity
WeatherGod commented on Sep 19, 2016
wow, that's a doozy. does this still happen in 2.0b4 with mpl.use('classic')? If so, then that image could be use for direct comparison with the 1.5 image to figure out the exact differences (did the y-spine or the x-spine shift?)
Kojoley commented on Sep 19, 2016
matplotlib.style.use('classic') does not help, v2.0.0b1-v2.0.0b4 are affected.
It is x-spine shift. Open the plot, make the window wide and then slowly resize it - you will see.
WeatherGod commented on Sep 19, 2016
You can't tell if it is an x or y spine shift to the right or left just by looking at one image. It has to be compared to a baseline - hence why classic mode would be helpful here since fonts and other settings have changed that would complicate direct comparisons.
anntzer commented on Sep 19, 2016
It does not happen in classic mode for me.
QuLogic commented on Sep 19, 2016
If you pan and zoom, the x spine jumps between alignment with the y spine and how it looks here. The y spine does not shift position.
Kojoley commented on Sep 19, 2016
I have this
QuLogic commented on Sep 19, 2016
It doesn't happen in classic mode with these axes limits for me, but if you pan around enough, it does happen in classic mode.
Kojoley commented on Sep 19, 2016
Try to resize the window
QuLogic commented on Sep 19, 2016
I can also trigger it in 1.5.2 as well, with careful panning. Sometimes can even save it as well:
4 remaining items
jklymak commented on Aug 7, 2019
We have to convert to float at some point. That involves an inherent loss in resolution over a given date range.
As pointed out numerous times, using matplotlib date plotting on timescales shorter than milliseconds will lead to inaccuracies and the user should just plot as seconds from the start of the day, or some other reference time. I really don’t think there is any advantage to specially handling dates at such a small scale.
anntzer commented on Aug 7, 2019
I'm actually fine with saying "we can't do anything about it", but I think if we can't even position plot elements accurately (if spines are at the wrong place it seems likely that other artists will be rendered at the wrong place too) then we should just error out. Or at least reword the warning in #15000 to something stronger: it's not that plotting microseconds at current reference times is "not well supported", it's that the plot may well have nothing to do with your actual data.
jklymak commented on Aug 7, 2019
That'd be fine. But we don't error out on other floating point inaccuracies, its just that this one is more unexpected.
One thing we could do is change the epoch to something more modern, like 1970, or 2000. Most people plotting old dates do not need millisecond accuracy.
jklymak commented on Aug 7, 2019
OK, what do you think about an mdates.set_epoch('1970-01-01') or some such? That would allow users who want to set today as the epoch get resolution out to very small numbers. Of course you would need to set the epoch before you start plotting, but that doesn't seem to be an issue to me.
anntzer commented on Aug 7, 2019
I guess that may be nice to have.
OTOH your comment about other floating point inaccuracies not being warned upon also convinced me that this may not be worth overthinking about.
jklymak commented on Aug 7, 2019
I did it. It works, down the point the microsecond locator gives up. But... we lose some guard-rails, like matplotlib times can't be less than 1. OTOH, not sure why that's really needed or desirable.
jklymak commented on Aug 7, 2019
I guess I'm still somewhat of the opinion that if you are going to go to the trouble of specifying an epoch, you might as well just subtract the epoch from the time and plot as floats yourself, but I could be convinced otherwise.
anntzer commented on Aug 7, 2019
Well we can still say "put your epoch to somewhere earlier than any date you're planning to use" and call it a day. We can even make date2num and friends set a global variable "a date conversion has been done" and make set_epoch error out if any date conversion has already been done (so that we don't end up with inconsistent epochs).
However I certainly also agree we may be overengineering this.
QuLogic commented on Apr 29, 2020
This should be fixed by #15008, assuming you use a recent epoch.