> > 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... _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
