Ted, I agree entirely--we do need a better date-handling module than what can be built on the feeble and clumsy datetime standard module. It would be nice to have this as part of numpy, so it can be vectorized from the start. I have some code that I use; I will have to check to see what its limits are.
Eric Ted Drain wrote: > Just a note (that I realize will probably never get 'fixed'): > > It would be nice if MPL could support more arbitrary date ranges (such as > negative numeric dates). This comes up more often than you might think. > Try writing a GUI w/ an embedded date plot - you can't switch a plot to date > format until you reset the range so it doesn't contain a zero and you can't > autoscale plots w/o data. In addition, we do plot things from a long time > ago every once in awhile. It would be nice if you could switch an arbitrary > plot to date format and not worry about the formatter throwing an exception > because the plot range isn't quite to its liking. There are algorithms for > handling numeric <-> calendar conversions that work for all time (at least > from 0 Julian Date == -4700'ish BC). > > http://en.wikipedia.org/wiki/Julian_date > > A switch to Julian date format for the numeric value would 'fix' these > problems though that would break existing data sets so I realize it's > unlikely to happen. > > At some point in the future, I'll put a little test case together to show > how the problems w/ not supporting a zero date show up in embedded plots. > > Ted > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Eric Firing >> Sent: Tuesday, June 03, 2008 1:29 PM >> To: Stephane Raynaud; John Hunter >> Cc: Matplotlib >> Subject: Re: [matplotlib-devel] date2num/num2date and ordinal date >> >> Stephane Raynaud wrote: >>> Hi, >>> >>> date2num and num2date perform conversion between datetime and 'days >>> since 0001-01-01' and vice versa. >>> For such task, they strictly use ordinal dates for their numeric >> days, >>> 1 meaning '0001-01-01' by definition. >>> Thus, date2num(datetime.datetime(1,1,1,0,0,0)) return 1. which is >>> supposed to mean '1 days since 0001', which is wrong (because it >>> points to datetime.datetime(1,1,2,0,0,0)). >>> >>> Since year zero cannot be used (here for time units) because it >>> doesn't exist, don't you think that the ordinal date >>> (datetime.datetime(1,1,2,0,0,0).tordinal()) should not be strictly >>> used as a reference numeric time, but its value-1? >> Stephane, yes, what you say makes sense. Long ago I settled on a >> convention of using "decimal days" referenced to the start of a >> "yearbase" for time calculations and for plotting variables against >> time. So if the yearbase is 2008, then noon on January 1 of 2008 is >> 0.5. The more common convention in oceanography, though, was to label >> days of the year with a 1-based count and then add the fraction of the >> day, so what is 0.5 to me is 1.5 to many others. In this case, where >> the time scale origin (the start of the yearbase) might be in the >> middle >> of one's time series, the decimal day definition is clearly superior >> (at >> least to me). But in the case of the matplotlib dates module the >> distinction is less important, because the origin is quite arbitrary >> and >> will almost always be far smaller than the minimum of the range >> plotted. >> The datenum is mainly useful for calculations, not for direct >> display. >> Note that the datetime module (and therefore mpl.dates) simply doesn't >> work for BC dates. >> >> Personally, I would be perfectly happy to implement your suggestion so >> that the reality would correspond to the dates module docstring; but >> maybe this would break some user code, so others might prefer to modify >> the docstring to reflect the present behavior instead. >> >> John, I suspect you wrote the dates module and use it heavily--what do >> you think about the two methods of bringing the docstring and the >> behavior into alignment? Any problem with fixing the behavior? >> >> Eric >> >> ----------------------------------------------------------------------- >> -- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> Checked by AVG. >> Version: 8.0.100 / Virus Database: 269.24.6/1480 - Release Date: >> 6/3/2008 7:00 AM > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
