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

Pierre GM pgmdevlist@gmail....
Fri Jul 11 11:10:23 CDT 2008


> We are planning to implement some date/time types for NumPy, and I'm
> sending a document that explains our approach.  We would love to hear
> the feedback of the NumPy community in order to cover their needs as
> much as possible.

That sounds like an excellent idea. Matt Knox and I tried something similar 
with the scikits.timeseries module we've been developing over the last 18 
months (scipy.org/scipy/scikits/wiki/TimeSeries).

Our approach for dealing with dates was to translate them into integers 
through a particular class (Date). The trick was to change the reference 
depending on the problem at hands: when dealing with annual series, the Date 
object is simply the year (since CE); when dealing with months, the number of 
months since 0CE; when dealing with hours, the number of hours since 1970... 
All the nitty-gritty parts were coded by Matt in C. And yes, we have routines 
to transform a datetime object into a Date object and back. We also used a 
parser from mxDate when dealing with dates in string formats.

We thought about creating specific dtypes to simplify the interface, but had 
problems finding proper documentation for that and were anyway more 
interested in having something running. The approach works well for us, but 
one of the biggest limitations we have is that we can't handle series with a 
frequency less than 1s (as we need integers), and your idea of a float for 
higher frequencies is great.

About the types you propose, isn't there a typo somewhere in the resolution ? 
What's the difference between your datetime64 and timestamp64 ?

> In this document, the emphasis has been put in comparing the
> compatibility of future NumPy date/time types against the ``datetime``
> module that comes with Python.  Should we consider the compatibility
> with mx.DateTime as well?  Are there many people using ``mx.DateTime``
> [2]_ out there?  If so, which are their advantages over ``datetime``
> module?.

mx.DateTime has a great parser for strings, but its use adds yet some other 
requirements (you need to have the module installed and it doesn't come by 
default with python, there's some licensing issues...), so I wouldn't focus 
on that for now, if I were you.

> A final note on time scales
> ---------------------------
Wow, indeed. In environmental sciences (my side) and in finances (Matt's), we 
very rarely have a need for that precision, thankfully...

More information about the Numpy-discussion mailing list