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
