Menu
▾
▴
Re: [matplotlib-devel] Date overhaul?
|
From: Thomas C. <tca...@gm...> - 2015-01-08 19:14:37
|
I was hoping for something a bit more extensive of the intenals. I have tried to understand the units code a couple of times now and always hit a brick wall. On Thu Jan 08 2015 at 2:07:02 PM Drain, Theodore R (392P) < the...@jp...> wrote: > Google search "matplotlib units" yields: > http://matplotlib.org/api/units_api.html > > > > So it sounds like the update is to make MPL's internal date system higher > resolution which would be great. We would just need to update our > converters to convert to that format instead of the current floating point > format. Our custom classes are not public (and can't really be made > public) but they aren't very complicated so we can certainly talk about the > implementation if that helps. > > > ------------------------------ > *From:* Thomas Caswell [tca...@gm...] > *Sent:* Thursday, January 08, 2015 10:57 AM > *To:* Drain, Theodore R (392P); mat...@li... > > *Subject:* Re: [matplotlib-devel] Date overhaul? > One of the other driving factors to over-haul the default date handling > is that floats do not have enough precision to deal with nano-second > resolution data (which is what I think drove pandas to use datetime64). > > It sounds like the correct solution > > Is the unit framework documented anywhere and are those custom classes > public? > > Tom > > On Thu Jan 08 2015 at 12:59:17 PM Drain, Theodore R (392P) < > the...@jp...> wrote: > >> I agree w/ the original poster that it would help to have a MEP to >> clearly define what the goals of the overhaul are >> >> >> >> Something else to keep in mind: we at least don't normally plot dates in >> "earth" based time systems. ~10 years ago we contracted with John Hunter >> to add the arbitrary unit system to MPL. This allows users to plot in >> their own data types and define a converter to handle the conversion to MPL >> types and labeling. We have our own "date time" like class which handles >> relativistic time scales (TDB, TT, TAI, GPS, Mars time, etc) at extremely >> high precision. We register a unit converter w/ MPL which allows our users >> to plot these types natively and use the xunits keyword (or yunits) to >> control how the plot looks. So we can do this: >> >> >> >> plot( x, y, xunits="GPS", yunits="km/s" ) >> >> plot( x, y, xunits="PST", yunits="mph" ) >> >> >> >> It would also be pretty easy to add a time zone aware unit converter with >> the existing MPL code which would allow you to do things w/ datetime like >> this: >> >> >> >> plot( x, y, xunits="UTC+8" ) >> >> plot( x, y, xunits="EST" ) >> >> >> >> I guess the point of this is to remind folks that not everyone plots >> dates in time zone based systems... >> >> >> >> Ted >> >> >> ------------------------------ >> *From:* Chris Barker [chr...@no...] >> *Sent:* Thursday, January 08, 2015 9:00 AM >> *To:* mat...@li... >> *Subject:* Re: [matplotlib-devel] Date overhaul? >> >> On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro <sk...@po...> >> wrote: >> >>> I'm real naive about this stuff, but I have always wondered why >>> matplotlib didn't just use datetime objects, or at least use >>> timezone-aware datetime objects as an "interchange" format to get the >>> timezone stuff right. >>> >> >> Time zone handling is a pain in the %}€* >> >> And the definitions keep changing. >> >> So you need a complex DB and library that needs frequent updating. >> >> This is why neither the standard library nor numpy support time zone >> handling out of the box. >> >> But the datetime object does support a hook to add timezone info. >> >> The numpy datetime64 may implementation _may_ provide a similar hook >> in the future. >> >> There is the pytz package, which MPL could choose to depend on. >> >> But even that is a bit ugly--e.g. from the pytz docs: >> >> """Unfortunately using the tzinfo argument of the standard datetime >> constructors ‘’does not work’’ with pytz for many timezones.""" >> >> So my suggestion is that MPL punts, and stick with leaving time zone >> handling up to the user, I.e only use datetimes that are timezone "naive". >> What this means is that MPL would always a assume all datetimes interacting >> with each other are in the same time zone (including same DST status). >> >> Anyway, I'm being a bit lazy here, so I may be wrong, but I think the >> issue at hand is that MPL currently uses a float array to store and >> manipulate datetimes, and the thought is that it may be better to use >> numpy datetime64 arrays -- that would give us more consistent precision, >> and less code to convert to/from various datetime formats. >> I'm a bit on the fence about whether it's time to do it, as datetime64 >> does have issues with the locale timezone, but as any implementation would >> want to work with not-just-the-latest numpy anyway, it may make sense to >> start now. >> >> -Chris >> >> >> >> >> >> >> -- >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R (206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> Chr...@no... >> ------------------------------------------------------------ >> ------------------ >> Dive into the World of Parallel Programming! The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is >> your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > ------------------------------------------------------------ > ------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
