On Thu, Jun 2, 2011 at 7:25 AM, Marc Shivers <marc.shiv...@gmail.com> wrote:
> 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).
>
What kind of functions/data would be needed for days with shorter trading
hours? The design I've sketched out supports everything you're describing
except things related to trading hours.
>
> 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.
>
I definitely agree, NumPy would have no knowledge of specifics, just a
mechanism to tell it when holidays are, etc, and do reasonable calculations
on them.
-Mark
>
> -Marc
>
> On Wed, Jun 1, 2011 at 7:47 PM, Wes McKinney <wesmck...@gmail.com> wrote:
> > On Wed, Jun 1, 2011 at 10:29 PM, Charles R Harris
> > <charlesr.har...@gmail.com> wrote:
> >>
> >>
> >> On Wed, Jun 1, 2011 at 3:16 PM, Mark Wiebe <mwwi...@gmail.com> wrote:
> >>>
> >>> On Wed, Jun 1, 2011 at 3:52 PM, Charles R Harris
> >>> <charlesr.har...@gmail.com> 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
> >> NumPy-Discussion@scipy.org
> >> 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
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
