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.

locator = AutoDateLocator(interval_multiples=True)
ax.xaxis.set_locator(locator)

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.

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.

I was goiong to plow ahead in #9801, but its a breaking change that'll require some buy-in.

ok, that would be great. Thanks.
So to summarise:

• Introduce minor ticks with hh:mm:ss or hh:mm
• Introduce major ticks with YYYY-MM-DD
• Improve checking for label overlaps

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

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)

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.

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

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

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.

Yeah, the heuristic for AutoLocator is 3-em. It usually works pretty well.

See #10841

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.