[Numpy-discussion] NumPy date/time types and the resolution concept
Thu Jul 17 03:10:13 CDT 2008
A Thursday 17 July 2008, Matt Knox escrigué:
> > Maybe you are right, but by providing many resolutions we are
> > trying to cope with the needs of people that are using them a lot.
> > In particular, we are willing that the authors of the timseries
> > scikit can find on these new dtype a fair replacement of their Date
> > class (our proposal will be not so featured, but...).
> I think a basic date/time dtype for numpy would be a nice addition
> for general usage.
> Now as for the timeseries module using this dtype for most of the
> date-fu that goes on... that would be a bit more challenging. Unless
> all of the frequencies/resolutions currently supported in the
> timeseries scikit are supported with the new dtype, it is unlikely we
> would be able to replace our implementation. In particular, business
> day frequency (Monday - Friday) is of central importance for working
> with financial time series (which was my motivation for the original
> prototype of the module). But using plain integers for the DateArray
> class actually seems to work pretty well and I'm not sure a whole lot
> would be gained by using a date dtype.
Yeah, the business week. We've pondered including this, but we are not
sure about the differences of such a thing and a calendar week in terms
of a time unit. I see for sure its merits on the TimeSeries module,
but I'm afraid that it would be non-sense in the context of a general
Now that I think about it, maybe we should revise our initial intention
of adding a quarter too, because ISO 8601 does not offer a way to print
it nicely. We can also opt by extending the ISO 8601 representation in
order to allow the next sort of string representation:
In : array([70, 72, 19], 'datetime64[Q]')
Out: array([1988Q2, 1988Q4, 1975Q3], dtype="datetime64[Q]")
but, I don't know if this would innecessarily complicate things (apart
of representing a departure from standards :-/).
> That being said, if someone creates a fork of the timeseries module
> using a new date dtype at it's core and it works amazingly well, then
> I'd probably get on board. I just think that may be difficult to do
> with a general purpose date dtype suitable for inclusion in the numpy
Yeah, I understand your reasons. In fact, it is a pity that your
requeriments diverge in some key points from our proposal for the
general dtypes. I have had a look at how you have integrated recarrays
in your TimeSeries module, and I'm sure that by choosing a date/time
dtype you would be able to reduce the complexity (and specially the
efficiency too) of your code quite a few.
More information about the Numpy-discussion