Francesc, > 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... _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion