Re: [Matplotlib-users] Date plotting

[John H. <jdh...@ac...>]

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> On Sat, 2004-05-08 at 20:47, John Hunter wrote:
    >> ax = subplot(111)
    >> 
    >> #your plot here for tick in ax.xaxis.get_minor_ticks():
    >> tick.label1.set_y(-0.1)
    >> 

    Steve> Thanks for the advice, but I tried this and the tick labels
    Steve> disappeared completely. I then tried tick.label1.set_y(0.0)
    Steve> which I would expect to leave the labels at the same place,
    Steve> but the labels disappeared also.

Doh!  There's a reason I try to never post untested code.  I wrongly
assumed the location were in relative axes coords but they are not.  I
use reference values (matplotlib.transforms.RRef - think mutable
floats or a c pointer to a float) in some instances to specify
locations.  I define binary operations on these so I can specify
locations like 3 points to the left of the x axis minimum, and have
these locations update automagically under figure resizes and dpi
changes - see http://matplotlib.sf.net/matplotlib.transforms.html.

This is what I do for x tick label locations - they are specified in
number of points below the minimum of the axes bounding rectangle.
Here is how to properly change that location (tested this time!)

from matplotlib.transforms import RRef
from matplotlib.matlab import *
ax = subplot(111)

plot([1,2,3])

points = 20
for tick in ax.xaxis.get_major_ticks():
    y = ax.bbox.y.get_refmin() - ax.dpi*RRef(points/72.0)
    tick.label1.set_y(y)
show()

ax.bbox.y.get_refmin(), ax.dpi and RRef(points/72.0) are all RRefs, as
is y.  

A word of warning.  I'm totally rewriting the transform architecture
from the ground up as we speak, so whatever you do here is likely to
change with the next release.  Of course there will be an analogous
way to do it and if you remind me I'll let you know what it is - or
you can check the code in XAxis.py to see how it specifies tick
locations.  In any case there will be release notes detailing the
changes.

    Steve> I had a look at matplotlib.dates and found what looks like
    Steve> a problem/limitation.  This is my understanding, which may
    Steve> be completely wrong.  The python 'time' module (and
    Steve> epochtime) limits years to 1970-2038.  The 'egenix' and
    Steve> python 'datetime' modules support a much larger range of
    Steve> years ('datetime supports years from 1-9999).

    Steve> matplotlib.dates converter classes supports 'epochtime',
    Steve> 'datetime' and 'egenix' date formats. However, internally
    Steve> it uses epochtime for all dates and so limits all years to
    Steve> the range 1970-2038, even though 'datetime' and 'egeinx'
    Steve> themselves support much more that this.

    Steve> I think there is a lot of data available before 1970 that
    Steve> people might like to plot. Taking stock data as an example,
    Steve> Yahoo has data going back to 1962 for some companies.

Absolutely right.  It ought to use datetime for everything if
python2.3 is available.  It's not a top priority for me right now
since I'm up to my elbows with the new transformation code, optimized
line and patch collection drawing, porting mathtext to PS and handling
newline separated strings, but I agree it is an important fix; I added
it to the priorities list.

JDH