On Jun 6, 2011, at 8:33 PM, Christopher Barker wrote: > Mark Wiebe wrote: >> I'm wondering if removing the business-day unit from datetime64, and >> adding a business-day API would be a good approach to support all the >> things that are needed? > > That sounds like a good idea to me -- and perhaps it could be a general > Calendar Functions API, to handle other issues as well.
+1 as well. > Looking again at the NEP, I see "business day" as a time unit, then > below, that "B" is interpreted as "24h, 1440m, 86400s" i.e. a day. Well, "B" was initially interpreted as Mon-Fri, which works well enough as long as you don't take holidays into account (that's how we did it in scikits.timeseries. > > Business days aside, I also see that months and years are given > "Interpreted as" definitions: > > Code Interpreted as > Y 12M, 52W, 365D > M 4W, 30D, 720h > > This is even self inconsistent: We had some neat conversion rules in scikits.timeseries, supporting years and months. It's not as messy as you want to convince yourself, don't worry ;) There was one issue, though. When converting to a higher frequency, we had to decide whether to put the new point at the beginning or the end of the period. That was managed through a keyword (see http://pytseries.sourceforge.net/generated/scikits.timeseries.TimeSeries.convert.html#scikits.timeseries.TimeSeries.convert for more details). But apart from that, it can be handled quite neatly. > > This goes to heck is the data is expressed in something like "months > since 1995-01-01" > > Because months are only defined on a Calendar. Using the ISO as reference, you have a good definition of months. _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
