also in 0.60.2 i noticed that ticker.DayMultiLocator is used
>> on line 1518 of matplotlib/axes.py but is not imported
> That was just after DayMultiLocator was added; it's a
> bug. You can just add it yourself. I use (a little
> modified) 60.2 as well on two production servers. It seems
> very stable at this point. Great majority of my plotting
> uses plot_date and with the new changes (haven't tried -
> just read about) I am afraid that lots of my code will
> break. So might take this opportunity to ask:
My apologies for the hassle. I suspect you'll find the conversion
painless when/if you can ever work yourself up to it. I converted all
the datetime example code in a matter of minutes
1) convert your epoch to proleptic gregorian dates(see below)
2) remove the converter instance from the calls to plot_date
3) check your tick locator constructors replacing all 'base'
constructors with explicit constructors (expect for the
YearLocator, which still take the base arg). Eg if you want even
months, do MonthLocator(range(2,13,2)) rather than MonthLocator(2)
> Does the new date plotting mechanism support the old way of
> using "seconds from epoch"? It was very efficient as a lot
> of data (not only mine I would imagine) is simply in that
> format.
I'll provide a converter func in the dates module. This is what I
think should be done, but I'll bounce it off the list to make sure.
Epoch time starts at 1970,1,1
>>> time.gmtime(0)
(1970, 1, 1, 0, 0, 0, 3, 1, 0)
>>> dt = datetime(1970, 1, 1, 0, 0, 0, tzinfo=None)
>>> dt.toordinal()
719163
So to convert to the new calendar, add 719163 and divide by seconds
per day. Since you can do this in numerix, it shouldn't impose a
noticeable performance hit on your script
import matplotlib.numerix as nx
from matplotlib.dates import num2date
def epoch2num(e):
spd = 24.*3600.
return 719163 + nx.asarray(e)/spd
e = range(0,20000,1000)
d = epoch2num(e)
print num2date(d[0])
If everyone is happy with the conversion function name and
implementation, I'll add it to the dates module.
JDH