[Numpy-discussion] RFC: A proposal for implementing some date/time types in NumPy
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
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``
> _ out there? If so, which are their advantages over ``datetime``
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