overall this seems fine. I suspect you need a minor API note that saysself.replaced has been dropped. This should probably never have been public in the first place, as I can't see why a user would do anything with it, but...

Is it worth putting in the a property what warns on get/set? On one hand, most likely no one is using this, on the other hand it is not much work to make sure we do not needlessly break anyone who is trying to access this.

I think this is fine. I'm guessing no one used this undocumented attribute.

Sorry, I should have noticed this the first time. You have also changed the signature of RRuleLocator. I think you need to write a new docstring for it, since it cannot simply inherit fromDateLocator any longer.

I'm actually not completely happy with that signature change yet. Calling the argument 'interval_multiples' is a bit confusing if it really only applies to yearly ticks.

Taking care of the special case directly in the RRuleLocator is best for overall clarity, imo. That's why I think this change is an improvement.

But I also want to achieve easy usage of the RRuleLocator for timedeltas at the same time. It already works for all frequencies except for daily. Daily with timedeltas is a very similar special case to yearly with dates. I'd like to subclass the RRuleLocator and only override init and the method that determines start, stop as multiples of the interval.

It might be better to have the signature be different between RRuleLocator and a subclass to make everything more clear?
For example, call the argument 'yearly_interval_multiples' maybe?

It would be best to have only one RRuleLocator class for dates and timedeltas. Also because of the locator classes for specific frequencies. As it looks, HourLocator can be used for dates and timedeltas. But DayLocator cannot be used for both because that is a special case with timedeltas. Ideally, all locators can be used for both. But I see no way currently to make that happen.

This is, of course, out of scope for this PR. But I do want to consider it already to facilitate the other PR.

If it really can't be done generally, then maybe a subClass make sense. In that case you could make it the same as the previous YearlyLocator, but hopefully with less repeated code because you now subclass RRuleLocator. That seems the most straightforward, and it stops RRuleLocator from having a bunch of extra logic?

That might actually be the best option. It still requires overwriting the.tick_values method in the yearly locator. There will be some very similar but slightly different code then. But less complex than the previous YearLocator. So an improvement after all.
And it keeps the extra logic out of the RRuleLocator, that's true. And it's not changing the signature of RRuleLocator.

But it also means that this has to stay inAutoDateLocator.get_locator():

  if (freq == YEARLY) and self.interval_multiples:      locator = YearLocator(interval, tz=self.tz)  elif use_rrule_locator[i]:      ...      locator = RRuleLocator(rrule, self.tz)

I don't particularly like this because it is not very flexible, considering an AutoTimedeltaLocator requires a different special case here. But maybe that's not a problem to solve here.

I'm not sure I follow this. Why do start and stop need to be multiples of the intervals? This either needs more comment, or cleaning up?

More comments probably? So, usually creating ticks on multiples of the interval is done by adjusting the "byranges". So for example with frequency =SECONDLY and interval = 15, the AutoDateLocator makesbyseconds = [0, 15, 30, 45].

But there is no "byrange" for years. Rrule can create a reoccurrence every 10 years (for example). But you cannot specify that you want that to be on every full decade only. It will be every 10 years starting with the start date. So to get multiples of the interval, start needs to be a multiple of the interval.

This is why AutoDateLocator currently returns an RRuleLocator for YEARLY when.interval_multiples = False, but a YearLocator for when it is true.

Stop can technically be a value greater than the last desired tick.

The comment is not very clear, I agree. It should probably be something like "start needs to be a multiple of the interval for ticks on interval multiples when freq == YEARLY"

But there is no "byrange" for years. Rrule can create a reoccurrence every 10 years (for example). But you cannot specify that you want that to be on every full decade only. It will be every 10 years starting with the start date. So to get multiples of the interval, start needs to be a multiple of the interval.

Probably something like this in the comments? That makes sense...

This needs to get hit by the tests somehow! Maybe not your fault - i.e. perhaps YEARLY wasn't in the tests really well before, but the new functionality should get a test.

Yes can you add a test for this. Otherwise I think this is good?

@jklymak done