On Jun 8, 2011, at 11:05 PM, Mark Wiebe wrote:
> The NEP and current implementation of the datetime specifies microseconds as
> the default unit when constructing and converting to datetimes and timedeltas.
AFAIU, the default is [us] when otherwise unspecified.
> Here are some current behaviors that are inconsistent with the microsecond
> default, but consistent with the "generic time unit" idea:
>
> >>> np.timedelta64(10, 's') + 10
> numpy.timedelta64(20,'s')
Here, the unit is defined: 's'
> >>> np.datetime64('2011-03-12') + 3
> numpy.datetime64('2011-03-15','D')
OK, here it is not. But the result makes sense... Up to a certain point. If you
try to guess the unit from a date given as a string, what happens in case of
ambiguities ? Or do you restrict an input string to be strictly ISO8601 to
remove those ?
> I'd like to make 'M8' and 'm8' be datetime data types with generic time units
> instead of microseconds as they are currently. This would also allow the
> possibility of extending the behavior of detecting the unit from the input
> string as:
>
> >>> np.datetime64('2011-03-12T13')
> numpy.datetime64('2011-03-12T13-0600','h')
>
> to also work with arrays, which currently work like this:
>
> >>> np.array(['2011-03-12T13', '2012'], dtype='M8')
> array(['2011-03-12T13:00:00.000000-0600', '2011-12-31T18:00:00.000000-0600'],
> dtype='datetime64[us]')
Why is the second one not '2012-01-01T00:00:00-0600' ?
Otherwise, I'm all for it.
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
