[Numpy-discussion] RFC: A proposal for implementing some date/time types in NumPy
Fri Jul 11 14:16:39 CDT 2008
Pierre GM wrote:
> but you can use integers/dates/strings as indices and get your
cool! I like that.
>>>> print example
> [Jul-2008 Aug-2008 Sep-2008 Oct-2008 Nov-2008 Dec-2008]
I like this -- seeing the integers for the times makes me wonder what
that point is -- we've all been using numbers for time for years already
-- what would a datetime array give us other than auto-conversion from
datetime objects, if it doesn't include nicer display, timedelta, etc.
>>>> print example.tovalue()
> [24091 24092 24093 24094 24095 24096]
And is that a regular array of integers?
>>>> print example.tolist()
> [datetime.datetime(2008, 7, 31, 0, 0), datetime.datetime(2008, 8, 31, 0, 0),
> Now that I think about this, wouldn't be better if, after the eventual
> introduction of the new datetime types in NumPy, the matplotlib would
> use any of these three and throw away their current datetime class?
yes, that would be better, but what to do during the transition?
> [Unless they have good reasons for keeping their epoch and/or scale]
If they do, they those should be taken into account when designing
numpy's datetime types.
> That's nice! But it would be even nicer if that could be integrated in
> general NumPy arrays after the introduction of the datetime types (just
> thinking aloud ;-)
what would using dates/strings as indices mean for general numpy arrays?
> That's ok. But my point is that this forces you to represent absolute
> dates, and that's what I was trying to avoid. The proposed date/time
> types could work either as absolute or relative, depending on the needs
> of the user. Only when converting them to the Python
> ``datetime.datetime`` containers a time origin will be set, and hence,
> they represents an absolute date then. However, if you convert the
> NumPy datetimes into a ``datetime.timedelta``, your times will continue
> to be relative. That would be utterly important so as not to clutter
> NumPy too much with another set of 'timedelta' types, IMO.
hmm -- I see the tradeoff, but I like the timedelta concept too. I'm
I'm also imaging some extra utility functions/method that would be nice:
to convert to hours (and days, and seconds, etc). And maybe some that
would create a DateTimeArray from various time units.
I often have to read/write data files that have time in various units
like that -- it would be nice to use array operations to work with them.
Christopher Barker, Ph.D.
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
More information about the Numpy-discussion