[Numpy-discussion] RFC: A proposal for implementing some date/time types in NumPy
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
> 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