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. >> >>> >>> 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
