That's odd. I would think that it makes more sense to set
> the format *before* the data is plot, not after.
> Probably a good thing for people like me who have never
> used Matlab.
This is not a matlab vs non-matlab thing, it's just a plain-ol-bug.
As far as I know, matlab doesn't have a concept of tick locators and
formatters, it's an idea loosely borrowed from pyx. The order of
operations bug crept in because matplotlib has a default tick locator
and formatter that are not appropriate for date plotting, and when you
call ax.plot_date, which just forwards the call on to ax.xaxis_date,
the tick locator and formatter were being forcibly reset to the
AutoDateLocator and AutoDateFormatter. If you are a naive user and
have done no customization, 99% of the time this is what you want. But
if you have set your DateFormatter or DateLocator already, then this
is not what you want.
I made a change will help: now I check and see of the
formatter/locator is of the right type before forcibly resetting, eg
def xaxis_date(self, tz=None):
thisformatter = self.xaxis.get_major_formatter()
if not isinstance(thisformatter, DateFormatter):
formatter = AutoDateFormatter(locator)
This will help, and should address your use case, but it is not a complete
solution because it doesn't cover the use-case where the user may have
supplied a custom date formatter not derived from DateFormatter. We'd
rather use duck-typing here rather than isinstance but there is no
clear way to do this. We might be able to manage this by checking for
explicit user calls to set_major_formatter and friends but this is
probably brittle. To address this (rare) use case, I've
modified the Axes.plot_date docstring:
Note if you are using, custom date tickers and formatters, it
may be necessary to set the formatters/locators after the call
Changes in svn.