[Numpy-discussion] fixing up datetime

Marc Shivers marc.shivers@gmail....
Thu Jun 2 09:57:48 CDT 2011


On Thu, Jun 2, 2011 at 10:16 AM, Mark Wiebe <mwwiebe@gmail.com> wrote:
> On Thu, Jun 2, 2011 at 7:25 AM, Marc Shivers <marc.shivers@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.

Now that I'm thinking about it, maybe a good way to deal with this
would be to just build two calendars, one for normal trading hours,
and one for short trading hours, and then just stack and sort them, so
maybe there's no need for a special method...


>>
>> 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 <wesmckinn@gmail.com> wrote:
>> > On Wed, Jun 1, 2011 at 10:29 PM, Charles R Harris
>> > <charlesr.harris@gmail.com> wrote:
>> >>
>> >>
>> >> On Wed, Jun 1, 2011 at 3:16 PM, Mark Wiebe <mwwiebe@gmail.com> wrote:
>> >>>
>> >>> On Wed, Jun 1, 2011 at 3:52 PM, Charles R Harris
>> >>> <charlesr.harris@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
>
>


More information about the NumPy-Discussion mailing list