Regarding business days, for financial data, trading days are determined by each exchange, so, in particular, there is no such thing as a US Trading Calendar, only a NYSE Calendar, NYMEX Calendar, etc, etc... . I think it would be useful to have functionality where you could start with a weekday calendar with specified normal trading hours and easily remove a list of non-trading days that the user specifies as well as modify the days where the trading hours are shorter (e.g. the day after thanksgiving).
I think anything more specific should probably be relegated to a specific package for financial calendars, as this entire topic gets very messy very fast. -Marc On Wed, Jun 1, 2011 at 7:47 PM, Wes McKinney <[email protected]> wrote: > On Wed, Jun 1, 2011 at 10:29 PM, Charles R Harris > <[email protected]> wrote: >> >> >> On Wed, Jun 1, 2011 at 3:16 PM, Mark Wiebe <[email protected]> wrote: >>> >>> On Wed, Jun 1, 2011 at 3:52 PM, Charles R Harris >>> <[email protected]> wrote: >>>> >>>> <snip> >>>> Just a quick comment, as this really needs more thought, but time is a >>>> bag of worms. >>> >>> Certainly a bag of worms, I agree. +1 >>> >>>> >>>> Trying to represent some standard -- say seconds at the solar system >>>> barycenter to account for general relativity -- is something that I think >>>> is >>>> too complicated and specialized to put into numpy. >>>> >>>> >>>> >>>> Good support for units and delta times is very useful, >>> >>> This part works fairly well now, except for some questions like what >>> should datetime("2011-01-30", "D") + timedelta(1, "M") produce. Maybe >>> "2011-02-28", or "2011-03-02"? >>> >>>> >>>> but parsing dates and times >>> >>> I've implemented an almost-ISO 8601 date-time parser. I had to deviate a >>> bit to support years outside the little 10000-year window we use. I think >>> supporting more formats could be handled by writing a function which takes >>> its date format and outputs ISO 8601 format to feed numpy. >> >> Heh, 10000 years is way outside the window in which the Gregorian calender >> is useful anyway. Now, strict Julian days start at the creation of the world >> so that's a real standard, sort of like degrees Kelvins ;) >> >>>> >>>> and handling timezones, daylight savings, >>> >>> The only timezone to handle is "local", which it looks like standard C has >>> a rich enough API for this to be ok. >>> >>>> >>>> leap seconds, >>> >>> This one can be mitigated by referencing TAI or GPS time, I think. POSIX >>> time looks like a can of worms though. >>> >>>> >>>> business days, >>> >>> I think Enthought has some interest in a decent business day >>> functionality. Some feedback from people doing time series and financial >>> modeling would help clarify this though. This link may provide some context: >>> http://www.financialcalendar.com/Data/Holidays/Formats >> >> Well, that can change. Likewise, who wants to track ERS for the leap >> seconds? >> >> I think the important thing is that the low level support needed to >> implement such things is available. A package for common use cases that >> serves as an example and that can be extended/modified by others would also >> be helpful. >> >> Chuck >> >> _______________________________________________ >> NumPy-Discussion mailing list >> [email protected] >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > > Being involved in financial data analysis (e.g. via pandas) this stuff > will affect me very directly. I'll get back to you soon with some > comments. > > - Wes > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
