On Thu, Jun 9, 2011 at 1:44 AM, Pierre GM <pgmdevl...@gmail.com> wrote:
> > > > The fact that it's a NumPy dtype probably is the biggest limiting factor > preventing parameters like 'start' and 'end' during conversion. Having a > datetime represent an instant in time neatly removes any ambiguity, so > converting between days and seconds as a unit is analogous to converting > between int32 and float32. > > Back to Dave's example, '2011' is not necessarily the same instant in time > as '2011-01'. The conversion from low to high frequencies requires some > reference. In scikits.timeseries terms, we could assume that 'START' is the > reference. No problem with that, if we can have a way to extend that (eg, > through some metadata). I tried something like that in the experimental > version of scikits.timeseries I was babbling about earlier... > I don't think you would want to extend the datetime with more metadata, but rather use it as a tool to create the timeseries with. You could create a lightweight wrapper around datetime arrays which exposed a timeseries-oriented interface but used the datetime functionality to do the computations and provide good performance with large numbers of datetimes. I would love it if you have the time to experiment a bit with the https://github.com/m-paradox/numpy branch I'm developing on, so I could tweak the design or add features to make this easier based on your feedback from using the new data type. Cheers, Mark > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion