Repository navigation
General poor default formatting of datetimes on plot x-axis #9978
Description
General poor default formatting of datetimes on plot x-axes
I find the default datetime formatting on the basic plot function to be very suboptimal, and often causes overlapping labels.
Some factors that I think are worth addressing:
- "DD hh:mm" format is commonly used, and is unfamiliar to most readers.
- Overlapping labels occurs frequently
It is obviously possible to improve date formatting through tick formatting, especially the use of major and minor tick formatting and positioning, but I find this very frustrating to do each time, and would appreciate an improved default functionality.
My suggestion would be to move the date to the major ticks, and time to minor ticks, with time only specified in the commonly known iso formats: "hh:mm" and "hh:mm:ss", and date set to the ISO format: "YYYY-MM-DD".
Or a minimal change would be to change the current functionality to default to "hh:mm" rather than "DD hh:mm"
Activity
jklymak commented on Dec 11, 2017
Completely agree.
See #9801 for a partial fix and some discussion. The formatting is a bit of a bigger project, but at least #9801 will force ticks to line up with reasonable places.
If you want to work around for the Auto tick locations, you will find the following improves things a good bit.
You can also set rcParams['date.autoformat.minute'] to something more to your liking (or maybe rcParams['date.autoformat.hour'] etc.) which will let you still use the AutoLocator.
IanButterworth commented on Dec 11, 2017
The AutoDateLocator tip is helpful, thanks!
Hopefully this catches the eye if anyone is currently working on this. If not, I may give it a shot.
jklymak commented on Dec 11, 2017
I was goiong to plow ahead in #9801, but its a breaking change that'll require some buy-in.
IanButterworth commented on Dec 12, 2017
ok, that would be great. Thanks.
So to summarise:
jklymak commented on Dec 12, 2017
Well, if you want to try the above, you should definitely go for it. But... I think you have a pretty specific case in mind that won't work for the default which can span centuries to milli-seconds.
Checking for overlaps is pretty tough. Better just to rotate the ticks...
IanButterworth commented on Dec 12, 2017
Agreed that it would be difficult to make a one-size-fits-all default, but I think it's worth trying, so happy to give it a shot.
I just got this out through default behaviour... To be fair, the datetime format is highly logical, but so not how we typically use datetime formats.. (I guess it would be nice if humans could naturally parse so logically)
jklymak commented on Dec 12, 2017
Is 12-11 the date? See, this is why its so subjective. My plan was to strip the date except when the day rolls over. Otherwise, I figure the user can put it in the xlabel if they need the date noted on the plot.
IanButterworth commented on Dec 12, 2017
I think this may be where it's worth learning from other plotting platforms.. matlab, plotly, gadfly etc.
I wonder if there's a generally accepted best for default behaviour on datetime plots
IanButterworth commented on Dec 12, 2017
And indeed, 12-11 is the date. I think the fact you have to ask illustrates the issue well!
Just to clarify, the plot I got out above was from default behaviour. That might not've been clear
afvincent commented on Dec 12, 2017
FWIW, checking for overlapping of the tick labels may be out of the scope of a PR that would try to get better defaults for datetime labels.
IIRC, it is a general “issue” of Matplotlib in the sense that (I think that ) it is difficult to know the effective size of the text boxes before rendering the figure and that for this reason the number of ticks that is used is actually simply based on heuristics. The problem is that those heuristics are likely to have been designed for “rather general” tick labels (i.e. a few digits I guess) while the datetime tick labels are usually significantly longer than numerical ones and thus more prone to overlapping. But it is quite easy to trigger a situation where even numerical tick labels with long formatting overlap as well.
jklymak commented on Dec 12, 2017
Yeah, the heuristic for AutoLocator is 3-em. It usually works pretty well.
jklymak commented on Mar 24, 2018
See #10841
jklymak commented on Jan 28, 2019
OK, I'm going to close this because #10841 is now available. Its not default (yet ;-)), but I think closes this PR. Feel free to discuss here if you disagree.