John, Thanks for your help. I'm still having a bit of
> trouble. Enclosed is the code and plot. I cannot figure
> out why the major ticks are at hour 16. What I want is for
> the major ticks to be at 2mar 00, 3 mar 00 etc. i.e. start
> at the xaxis origin.
You always seem to find the pesky bugs, Jim!
Hmm, 24-16 = 8. You're not in California are you? llnl. I guess so.
8 hours is the time zone offset right now from GMT in California, I
believe.
When I initially wrote the dates module, I included timezone support.
This proved too difficult to do right w/ python2.2 (no datetime
module) and I gave up and decided to do everything in localtime. At
that time I converted everything from epoch gmtime to epoch localtime,
but failed to fix the date tick locators which derive from
MultipleLocators. These tick locators are looking for multiples of
some number of seconds (eg 24*60*60 for the day locator) since the
epoch. But when I converted from gmtime to localtime as the
underlying time frame, I introduced the bug, because
import datetime, time
spd = 3600*24 # sec per day
d = datetime.datetime( 2000, 3, 2)
e = time.mktime(d.timetuple())
print divmod(e,spd)
print 'gmoff', time.mktime(time.gmtime(0))
I'm introducing a temporary fix to ticker.py, attached to this email,
which addresses this problem. I'm a bit tired right now and am not
sure I've got it right, but it appears to behave properly. Basically,
I'm passing a localtime offset to the multiple locator. This is just
a temporary fix, and is likely to behave badly over time ranges that
span a daylight savings time shift. But it may be a decent temporary
fix for you. It seems to handle your case, and the others I tested,
at least.
I think I'll have to jettison python2.2 support for dates. timezones
and DST and the like are just too hard to do w/o the datetime module.
I think a rewrite of the dates module is in order, and at that time
the numeric representation of dates need to be expanded (eg to be able
to handle dates since before the 1972 epoch). That limitation was
imposed because I was relying on the time module under the hood. I
think I'll require python2.3 and datetime for the next go round, to
provide decent handling of timezones and DST.
Any suggestions about a proper numeric type for handling dates and
other suggested changes to the dates and date ticking welcome.
JDH
ticker.py (28.4 KB)