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

Pierre GM pgmdevlist@gmail....
Fri Jul 11 14:22:30 CDT 2008

On Friday 11 July 2008 14:58:33 Francesc Alted wrote:
> > Well, we coded something like that in our TimeSeries class: its
> > __getitem__ is quite bloated, but you can use integers/dates/strings
> > as indices and get your result. We implemented in Python, so that's
> > slow, but it works great.
> 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 ;-)

Oh yes. Matt and I have the plan to implement that part in C, but I doubt it's 
gonna happen anytime soon: I'd have to learn proper C first and 

> > About the representation (datetime vs integer):  
> That's ok.  But my point is that this forces you to represent absolute
> dates, and that's what I was trying to avoid.  

Mmh, it's only a matter of repr/str, in fact. Internally, your array would 
still be datetime64, and you'll leave the user decide how s/he wants to 
display it.

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

With DateArray, timedeltas are just integers, the behaviour depends on the 
objects they're added to. With a annual DateArray, +1 means "add one year". 
With a monthly DateArray, it means "add one month", and so forth...

More information about the Numpy-discussion mailing list