In general I'm not in favour of this PR, simply because it seems that it creates not enough labels for the general case and the determination of the spacing seems to be rather arbitrary. Adding this either as a differentWideSpreadAutoDateLocator or via an argumentAutoDateLocator(spread="generous") to the existing one seems to make more sense to me.

Else, I would argue that the spreading needs to take into account theactual fontsize (not the one from rcParams) and also the rotation of the labels - but that may be rather difficult, because those are not know before drawtime, right?

I think tick locators are determned at draw time, so thats OK, but you are correct that it should use the actual fontsize of the tick labels, not the one from rcParams!

I think the trouble with estimating the actual size would require the Text objects. Due to the order in which we use the locators in Axis's iter_ticks() there will be no text when we determine the number of ticks, which is the main cause of this issue. Also, any suggestions on retrieving the width of the axis?

Rotation:
When dealing with the xAxis (and yAxis) class which is what we have access to in DateLocator, I was not able to retrieve the rotation of the labels, I believe because it does not set rotation before determining the number of intervals.

Font size of tick labels:
As mentioned above, I believe the tick labels are empty because it decides the number of ticks before it gets the tick labels.

Not enough labels:
I think this issue goes hand in hand with rotation, as in when is it possible to determine if its rotated or not, in other words we need to know its going to be rotated before we place the number of ticks.

AutoDateLocator with parameter:
This is preferable but our parameter would go up to Axis, in particular:
Tick uses converter.axisinfo(self.units, self) which calls AutoDateLocator. So if i'm not mistaken the parameter (spread="generous") would be a property of the Artist class.

I will try to implement DateLocator with this parameter.

To make some progress and ensure previous image tests are preserved, I added rcParams["autodatelocator.spacing"] and I am using the axis's label for font and axis's figure for figsize. However I do have some concerns:

1. @jklymak is the width of the axes calculated before those intervals are placed? if so I am not able to determine how from the axis. I also have same question to get width from the label'sText, not sure which property to investigate.

@shadidsh the width of theaxes can be got fromax.get_position(original=False). Its in figure-normal co-ordinates, so you should use a transform to get to inches.

There seem to be several test image changes with imperceptible differences, leading me to think these images should not be changing at all.

I removed the unnecessary images, after changes to the PR I did not check them out properly.

The code now uses the axes width transformed from the axes's position. Please note the reason I added the parameter to RcParams is because rotation of label at this point does not seem to be set, thus spacing would be problematic. Any feedback and suggestions would be greatly appreciated, thanks.

Some comments provided.

I'm 50/50 on the PR as a whole. The issue is that most of the time dates on the xaxis are too long. What'll happen here is that there will just be too few ticks. The real solution is making the ticklabels shorter (i.e.#10841) and rotating the ticklabels.

@jklymak Thanks so much for the feedback, when i get the chance I will add the fixes for experience so I am fine if the PR is closed after the update.

@shadidsh thanks so much for the PR. Sorry that it didn't make it in, but it was a good idea. We are curretnly discussing tick-related issues, with an idea to completely overhaul them in 3.0. Now that you have some development experience under your belt, please feel free to contribute to that discussion.@timhoffm is leading it, though for the life of me, I can't remember or find what the issue is.

@timhoffm can we open a modern issue, w/ you as the author, to keep track of tick-related things...

@shadidsh hopefully we see more of you! Thanks again.