[Numpy-discussion] fixing up datetime
Marc Shivers
marc.shivers@gmail....
Thu Jun 2 07:25:06 CDT 2011
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 <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
>
More information about the NumPy-Discussion
mailing list