[Numpy-discussion] RFC: A proposal for implementing some date/time types in NumPy

[Christopher Barker]

Pierre GM wrote:
> but you can use integers/dates/strings as indices and get your 
> result.

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), 

nice, too.

> 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 
ambivalent now...

I'm also imaging some extra utility functions/method that would be nice:

aDateTimeArray.hours(dtype=float)

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.

-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.Barker@noaa.gov