On Fri, Apr 11, 2014 at 4:58 PM, Stephan Hoyer
On Fri, Apr 11, 2014 at 3:56 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
Are we in a position to start looking at implementation? If so, it would be useful to have a collection of test cases, i.e., typical uses with specified results. That should also cover conversion from/(to?) datetime.datetime.
yup -- tests are always good! Indeed, my personal wish-list for np.datetime64 is centered much more on
robust conversion to/from native date objects, including comparison.
A good use case.
Here are some of my particular points of frustration (apologies for the thread jacking!): - NaT should have similar behavior to NaN when used for comparisons (i.e., comparisons should always be False).
make sense.
- You can't compare a datetime object to a datetime64 object.
that would be nice to have.
- datetime64 objects with high precision (e.g., ns) can't compare to datetime objects.
That's a problem, but how do you think it should be handled? My thought is that it should round to microseconds, and then compare -- kind of like comparing float32 and float64...
Pandas has a very nice wrapper around datetime64 arrays that solves most of these issues, but it would be nice to get much of that functionality in core numpy,
yes -- it would -- but learning from pandas is certainly a good idea.
from numpy import datetime64 from datetime import datetime
print np.datetime64('NaT') < np.datetime64('2011-01-01') # this should not to true print datetime(2010, 1, 1) < np.datetime64('2011-01-01') # raises exception print np.datetime64('2011-01-01T00:00', 'ns') > datetime(2010, 1, 1) # another exception print np.datetime64('2011-01-01T00:00') > datetime(2010, 1, 1) # finally something works!
now to get them into proper unit tests.... -CHB -- 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.Barker@noaa.gov