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 [tcasw...@gmail.com]
Sent: Thursday, January 08, 2015 10:57 AM
To: Drain, Theodore R (392P); matplotlib-devel@lists.sourceforge.net
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)
<theodore.r.dr...@jpl.nasa.gov<mailto:theodore.r.dr...@jpl.nasa.gov>> 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 [chris.bar...@noaa.gov<mailto:chris.bar...@noaa.gov>]
Sent: Thursday, January 08, 2015 9:00 AM
To:
matplotlib-devel@lists.sourceforge.net<mailto:matplotlib-devel@lists.sourceforge.net>
Subject: Re: [matplotlib-devel] Date overhaul?
On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro
<s...@pobox.com<mailto:s...@pobox.com>> 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
chris.bar...@noaa.gov<mailto:chris.bar...@noaa.gov>
------------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net<mailto:Matplotlib-devel@lists.sourceforge.net>
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
