From: Delbert D. F. <iq...@so...> - 2005-02-02 18:10:57
|
John, thanks for the updated mx2num but I still found something puzzling: date2num takes the timezone from the matplotlibrc file but mx2num must take it from some info on my machine. There is a consistent seven hour difference between the two even though the datetime instances give exactly the same time. I need to point out that in my applications I have no interest in the time zone and I want it always treated as if I am on the Greenwich Meridian. Here's why: My simulation software has used what is essentially the modified Julian Day number from astronomy with a zero point around 1878 or so. I just add the fraction of the day to it. This works fine in my applications because there is no data to run the model earlier than about the 1900! Also I have users in different time zones sending me test cases and it would be a mess to have to somehow always adjust for time zone. Thus I have effectively computed the day numbers relative to the local time zone always. Another benefit is that there is a fixed offset between my time scale and the one used in plot_dates. Makes life a little simpler. Questions: 1. Should mx2num use a different time zone than does date2num? 2. If so, how do I get mx2num at its invocation only, to use the time zone in the matplotlibrc file? I assume I have to use the set_tzinfo method right before mx2num is invoked and then use set_tzinfo again right after to return to what it was. Heres an example test file: from matplotlib.dates import mx2num, date2num import datetime import mx.DateTime for ihr in xrange(24): yr = 2003 mn = 10 day = 20 imin = 30 second = 0.0 isec = 0 dt = mx.DateTime.DateTime(yr, mn, day, ihr, imin, second) dt2 = datetime.datetime(yr, mn, day, ihr, imin, isec) print 'hour=', ihr print 'mx dt=',dt print 'dt2=', dt2 diff = mx2num(dt) - date2num(dt2) print 'mx2num(dt)=',mx2num(dt) print 'date2num(dt2) =', date2num(dt2) print 'difference=', diff*24.0 print ' ' Here's some output at my time zone: hour= 0 mx dt= 2003-10-20 00:30:00.00 dt2= 2003-10-20 00:30:00 mx2num(dt)= 731508.3125 date2num(dt2) = 731508.020833 difference= 6.99999999907 hour= 1 mx dt= 2003-10-20 01:30:00.00 dt2= 2003-10-20 01:30:00 mx2num(dt)= 731508.354167 date2num(dt2) = 731508.0625 difference= 6.99999999907 hour= 2 mx dt= 2003-10-20 02:30:00.00 dt2= 2003-10-20 02:30:00 mx2num(dt)= 731508.395833 date2num(dt2) = 731508.104167 difference= 7.00000000186 hour= 3 mx dt= 2003-10-20 03:30:00.00 dt2= 2003-10-20 03:30:00 mx2num(dt)= 731508.4375 date2num(dt2) = 731508.145833 difference= 6.99999999907 hour= 4 mx dt= 2003-10-20 04:30:00.00 dt2= 2003-10-20 04:30:00 mx2num(dt)= 731508.479167 date2num(dt2) = 731508.1875 difference= 6.99999999907 hour= 5 mx dt= 2003-10-20 05:30:00.00 dt2= 2003-10-20 05:30:00 mx2num(dt)= 731508.520833 date2num(dt2) = 731508.229167 difference= 7.00000000186 Delbert |
From: Delbert D. F. <iq...@so...> - 2005-02-02 18:31:33
|
I just did another test. mx2num fails for dates prior to 1970 because it uses the magical Unix seconds from epoch. We need mx2num to work for the whole range of dates for which date2num works-at least that is my vote. Delbert On Wednesday 02 February 2005 10:10 am, Delbert D. Franz wrote: > John, thanks for the updated mx2num but I still found something > puzzling: date2num takes the timezone from the matplotlibrc file > but mx2num must take it from some info on my machine. There is a > consistent seven hour difference between the two even though the > datetime instances give exactly the same time. > > I need to point out that in my applications I have no interest in > the time zone and I want it always treated as if I am > on the Greenwich Meridian. Here's why: My simulation software > has used what is essentially the modified Julian Day number > from astronomy with a zero point around 1878 or so. I just add > the fraction of the day to it. This works > fine in my applications because there is no data to run the model > earlier than about the 1900! Also I have users in different time > zones sending me test cases and it would be a mess to have to > somehow always adjust for time zone. Thus I have effectively > computed the day numbers relative to the local time zone always. > > Another benefit is that there is a fixed offset between my > time scale and the one used in plot_dates. Makes life a little > simpler. > > Questions: > > 1. Should mx2num use a different time zone than does date2num? > > 2. If so, how do I get mx2num at its invocation only, to use > the time zone in the matplotlibrc file? I assume I have > to use the set_tzinfo method right before mx2num is invoked > and then use set_tzinfo again right after to return to > what it was. > > Heres an example test file: > > from matplotlib.dates import mx2num, date2num > import datetime > import mx.DateTime > > for ihr in xrange(24): > yr = 2003 > mn = 10 > day = 20 > imin = 30 > second = 0.0 > isec = 0 > > dt = mx.DateTime.DateTime(yr, mn, day, ihr, imin, second) > dt2 = datetime.datetime(yr, mn, day, ihr, imin, isec) > print 'hour=', ihr > print 'mx dt=',dt > print 'dt2=', dt2 > diff = mx2num(dt) - date2num(dt2) > print 'mx2num(dt)=',mx2num(dt) > print 'date2num(dt2) =', date2num(dt2) > print 'difference=', diff*24.0 > print ' ' > > > Here's some output at my time zone: > > > hour= 0 > mx dt= 2003-10-20 00:30:00.00 > dt2= 2003-10-20 00:30:00 > mx2num(dt)= 731508.3125 > date2num(dt2) = 731508.020833 > difference= 6.99999999907 > > hour= 1 > mx dt= 2003-10-20 01:30:00.00 > dt2= 2003-10-20 01:30:00 > mx2num(dt)= 731508.354167 > date2num(dt2) = 731508.0625 > difference= 6.99999999907 > > hour= 2 > mx dt= 2003-10-20 02:30:00.00 > dt2= 2003-10-20 02:30:00 > mx2num(dt)= 731508.395833 > date2num(dt2) = 731508.104167 > difference= 7.00000000186 > > hour= 3 > mx dt= 2003-10-20 03:30:00.00 > dt2= 2003-10-20 03:30:00 > mx2num(dt)= 731508.4375 > date2num(dt2) = 731508.145833 > difference= 6.99999999907 > > hour= 4 > mx dt= 2003-10-20 04:30:00.00 > dt2= 2003-10-20 04:30:00 > mx2num(dt)= 731508.479167 > date2num(dt2) = 731508.1875 > difference= 6.99999999907 > > hour= 5 > mx dt= 2003-10-20 05:30:00.00 > dt2= 2003-10-20 05:30:00 > mx2num(dt)= 731508.520833 > date2num(dt2) = 731508.229167 > difference= 7.00000000186 > > Delbert > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > |
From: John H. <jdh...@ac...> - 2005-02-02 19:04:55
|
>>>>> "Delbert" == Delbert D Franz <iq...@so...> writes: Delbert> I just did another test. mx2num fails for dates prior to Delbert> 1970 because it uses the magical Unix seconds from epoch. Delbert> We need mx2num to work for the whole range of dates for Delbert> which date2num works-at least that is my vote. Delbert Delbert> On Wednesday 02 February 2005 10:10 am, Delbert D. Franz wrote: If you feel up to making an mx2num that satisfies these requirements, I'm happy to include it as a patch. JDH |