[Numpy-discussion] fixing up datetime
Wed Jun 8 19:26:36 CDT 2011
On Tue, Jun 7, 2011 at 7:28 PM, Pierre GM <email@example.com> wrote:
> > It supports .astype(), with a truncation policy. This is motivated
> partially because that's how Pythons integer division works, and partially
> because if you consider a full datetime '2011-03-14T13:22:16', it's natural
> to think of the year as '2011', the date as '2011-03-14', etc, which is
> truncation. With regards to converting in the other direction, you can think
> of a datetime as representing a single moment in time, regardless of its
> unit of precision, and equate '2011' with '2011-01', etc.
> OK from high to low, less from low to high. That's where our keyword ('END'
> or "START") comes into play in scikits.timeseries, so that you can decide
> whether '2011' should be '2011-01' or '2011-06'...
Because datetime64 is a NumPy data type, it needs a well-defined rule for
these kinds of conversions. Treating datetimes as moments in time instead of
time intervals makes a very nice rule which appears to be very amenable to a
variety of computations, which is why I like the approach.
> > We needed the concept to convert time series, for example from monthly to
> quarterly (what is the first month of the year (as in succession of 12
> months) you want to start with ?)
> > Does that need to be in the underlying datetime for layering a good
> timeseries implementation on top?
> Mmh. How would you define a quarter unit ? [3M] ? But then, what if you
> want your year to start in December, say (we often use DJF/MAM/JJA/SON as a
> way to decompose a year in four 'hydrological' seasons, for example)
With origin metadata I suppose defining these things as NumPy data types
will work, but it still feels like it belongs at a higher level. Of course
I'm not going to stop anyone from doing it...
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion