It may be that I misunderstand something here, but shouldn't the date format be determined though the rcParamsdate.autoformatter.xyz parameters?

@ImportanceOfBeingErnest

The current formatters are:

# date.autoformatter.year     : %Y# date.autoformatter.month    : %Y-%m# date.autoformatter.day      : %Y-%m-%d# date.autoformatter.hour     : %m-%d %H# date.autoformatter.minute   : %d %H:%M# date.autoformatter.second   : %H:%M:%S# date.autoformatter.microsecond   : %M:%S.%f

and which one gets used is set by logic insidedates.py that chooses which interval is most appropriate. But only one formatter gets used for every tick once that formatter is chosen.

This PR takes into account surrounding ticks and changes the format accordingly. For instance, its extra info to repeat2009-01- for all the ticks in the "Days" example above, or the date in the "Hours" example. Taking into account the surrounding ticks to minimize visual clutter is what this PR does.

It would make sense for this PR to have a way to specify the format of the individual date elements - there are already placeholders for that. i.e.

self._yearfmt='%Y'self._monthfmt='%b'self._dayfmt='%d'# etc...

but I've not added RC params or kwargs yet.

It would of course be necessary to get the old behaviour back, either by leaving it the default, or by leaving instructions:

locator=mdates.LegacyAutoDateLocator()formatter=mdates.LegacyAutoDateFormatter(locator)ax.yaxis.set_major_locator(locator)ax.yaxis.set_major_formatter(formatter)

I see. Just note that it is very convenient to set the preferred format once through the rcParams and have every plot the way you want it. So if that is going to change, intruducing a parameter which reverts back would definitely be useful,date.autoformatter.use : old or similar.

@ImportanceOfBeingErnest That makes sense to me.

It sounds like we are also moving to a "startup-file" like startup sequence, so folks will be able to put slightly more sophisticated recipes in their newmatplotlibrc.py, like changing the default date handler. However I'm not sure if the architecture of that file is going to just affect rcParams, or arbitrary code. I think the former, so some way for rcParams to specify the DateFormatter is what will be needed. ie.rcParams['dates.locator']=mdates.LegacayAutoDateLocator

This PR takes into account surrounding ticks and changes the format accordingly. For instance, its extra info to repeat 2009-01- for all the ticks in the "Days" example above, or the date in the "Hours" example. Taking into account the surrounding ticks to minimize visual clutter is what this PR does.

This seems to be somethingused downstream in ObsPy (e.g., onwaveform plots). I have not looked at or compared either implementation though.

@QuLogic I think ObPy just makes the first tick have more info, but doesn't try to be intelligent about
which tick gets the extra info. This PR makes, for instance, midnight be labeled by the day, or second zero labeled by HH:MM, or 1 Jan by YYYY, etc. Note I've mildly improved the plot above...

Working through the example, I think my question may be more of what resolution does the formatter pick up?

fig,ax=plt.subplots()t0=datetime.datetime(2009,1,20)tf=datetime.datetime(2009,1,21)ax.axvspan(t0,tf,facecolor="blue",alpha=0.25)ax.set_xlim(t0-datetime.timedelta(days=5),tf+datetime.timedelta(days=5))ax.vlines([datetime.datetime(2009,1,17,5)+datetime.timedelta(hours=x)forxinrange(0,200,25)],0,1)ax.set_ylim(0,1)plt.show()

@story645 It returns:

Note this doesn't change the locator (which chooses the ticks), it sets the formatter.

Actually, coming back to the comment about localization mentioned during the call:

1. In the "hours" example, can "Aug-21" be replaced by "Aug 21"? (looks better even in English) (and in general, perhaps just get rid of the dashes?)
2. in French, that gives "août-21" and "2009-août-20" ("minutes" example), both of which are quite weird in French (I'd say "21 août", "21 août 2009").

A quick search did not yield any way to obtain localized separators or formats (especially "date without year") though :/ Not saying this should be a blocker, but just raising the issue.

I'm fine w/o the dashes. Easy change.

I'm personally against any formats that don't go year month day. As someone who writes hand written logs, nothing drives me nuttier than seeing "12-11-10" in a log book I know was written in November 2010, even though I would totally say 12 November 2010 in speech; written and spoken speech and scientific notation on a plot can/should be different.

@jklymak thanks! This only works with the major locator? (And I know that's probably a question about the autoformatter in general...)

Ummm... I think you can pass whatever formatter you want:

ax.yaxis.set_minor_formatter(formatter)

I think to make nicely formatted labels for minor date ticks would be a challenge given that they are already too big for normal axes sizes!

I think having a decent minor locator would be a fun challenge, but one thing at a time ;-)

This was largely met w/ approval on the call to turn this intoAutoDateFormatter, and move the currentAutoDateFormatter to aMpl22DateFormatter so folks could still access it. But some key folks weren't on the call.@tacaswell and@efiring, or anyone else want to weigh in before I do all the work of changing it?

@ImportanceOfBeingErnest I'll still try to figure out the best API for getting the old behaviour back, and ping you for your opinion.

Since my opinion on this is being asked for: I would not change the name.AutoDateFormatter is the automatic formatter which labels the ticks according to the rules given in thedate.autoformatter.xyz rcParams. I would leave it at this, because this is how people use it now and will still want to use it. There are all kinds of useful as well as weird standards for datetime formats and indeed as@anntzer commented, different language backgrounds need different formatting capabilities. They might have set their rcParams up to do the plots they like that way and I think one should not require them to change anything more than possibly add a single additional rcParam to get the old behaviour back.

In view of that I could imagine to allow the rcParamdate.formatter : auto to get theAutoDateFormatter.

Concerning the new formatter: I'm not sure if I grasp this correctly. Does it not allow to specify any custom formats for individual components like days, minutes, years etc, or is it still not decided? As the overall aim of the new formatter seems to be to have nicely looking plots I could imagine to name itPrettyDateFormatter. Setting this would then be done via the rcParamdate.formatter : pretty, which would also be the default if that is what people agree upon.

Thanks - I'll certainly make it so the current behaviour is achievable with rcParams.

As written the new formatter does not allow you to pass different formats for the elements. It'd be nice if it did. My tendancy would be to try to make it fit into one rcParam versus six or seven, but I'd have to think about whether parsing a format string is the best way to do that or passing a dict. Kind of needs@anntzer new rcParam methodology in place to see how that'll work 😉

Thanks@QuLogic - one of your comments I didn't grok, and a couple of them I think can be left to future efforts (parameterizing the tests)....

Pinging for this to be merged...

It's notparticularly hard (keep track of the various foo_formats in copies and see whether things have been invalidated); the question is just whether the whole thing is worth it.

Of course the datetime formattersalready break the underlying assumption that formatters operate independently of locators and format each value independently of the others: the formatter proposed by this PR needs to call (n times... even with the fix above)self._locator() to know what areall the tick values before formatting each of them (or, with the fix above, to see whether invalidation occurred). Which again argues that formatters should just grow aformat_tick_labels(self, ticks) (name up to bikeshedding) method that computes all the labels in one go. Actually now that I think of it, it's not even that hard to do the API change while providing a deprecation period for third-party formatters (if there's noformat_tick_labels, then fallback on calling__call__n times after emitting a DeprecationWarning).

Added the check. It wasn't the hardness of it that I was worried about, it was just the performance. But the algorithm itself is a bit of a pig, so I think its worth adding the checks.

Rebased. Ithink this is OK to merge assuming it all passes CI

This has two approvals - would someone do the honours and merge it?

Let's roll.

Thanks@anntzer (ahem, particularly as you don't use date times very much 😉)