<div class="gmail_quote">On Tue, Jun 7, 2011 at 7:28 PM, Pierre GM <span dir="ltr"><<a href="mailto:pgmdevlist@gmail.com">pgmdevlist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">><br>
> 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.<br>

<br>
</div>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'...<br>

<div class="im"></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> 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 ?)<br>

><br>
> Does that need to be in the underlying datetime for layering a good timeseries implementation on top?<br>
<br>
</div>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)<br>
</blockquote><div><br></div><div>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...</div>
<div><br></div><div>-Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br>