One year NYSE test that buys a lot triggers 492,963 calls to
minute_to_session_label. Only 98924 ~(390 * 252) make it past the
cache and trigger the heavier computation.
Remove module scope invocations of `get_calendar('NYSE')`, which cuts
zipline import time in half on my machine. This make the zipline CLI
noticeably more responsive, and it reduces memory consumed at import
time from 130MB to 90MB.
Before:
$ time python -c 'import zipline'
real 0m1.262s
user 0m1.128s
sys 0m0.120s
After:
$ time python -c 'import zipline'
real 0m0.676s
user 0m0.536s
sys 0m0.132s
The new TradingCalendar method is called `minute_index_to_session_labels`.
It takes a DatetimeIndex of in-order market minutes and returns a
DatetimeIndex of the corresponding sessions.
The new method is approximately 100x faster than mapping
`minute_to_session_label` over a large DatetimeIndex.
Encapsulate the shared global calendar map in an object.
This allows consumers that don't want to participate in custom
registration to pass around a calendar dispatcher, and would make it
easier to support contextual management of the global calendar map if we
want to do that in the future.
As a bonus, we now only create one instance of each calendar, instead of
one per alias.
* BUG: Further corrections for days_at_time
- Revert to using DateOffset, as Timedelta doesn't handle offsetting by
one day over a tz change properly:
In [12]: pd.Timestamp('2004-04-05', tz='America/Chicago') + pd.Timedelta(days=-1)
Out[12]: Timestamp('2004-04-03 23:00:00-0600', tz='America/Chicago')
In [13]: pd.Timestamp('2004-04-05', tz='America/Chicago') + pd.DateOffset(days=-1)
Out[13]: Timestamp('2004-04-04 00:00:00-0600', tz='America/Chicago')
By creating a DateOffset using the `days` kwarg, the issue previously
fixed in bcc867b is addressed.
- To preempt any other pandas issues around day offsets, changes to
performing these with no timezone, then localizing to the local
timezone when shifting the time.
- Adds unit test for days_at_time
* STY: Remove unused import
Prior to pandas 17, there were issues with offsetting dates with
DateOffset around discontinuities (like the start of DST). We can use
Timedelta here instead, which handles these edge cases.
Instead of having separate ExchangeCalendar and TradingSchedule objects, we
now just have TradingCalendar. The TradingCalendar keeps track of each
session (defined as a contiguous set of minutes between an open and a close).
It's also responsible for handling the grouping logic of any given minute
to its containing session, or the next/previous session if it's not a market
minute for the given calendar.
Since the CME calendar was based off of the NYSE calendar, closings for
Hurricane Sandy were included, but shouldn't have been for CME.
This is the explanation we had included prior to the new exchange
calendars:
http://en.wikipedia.org/wiki/Hurricane_sandy
We *do not* add any non-trading days for Hurricane Sandy. Although
trading on CME Group exchanges was disrupted, trading still occurred at
some point on each day. Importantly, the disruptions do not appear to
have affected the expiration dates stipulated in the futures contracts
expiring during this period.
Trading of CME US equity index futures & NYMEX futures was disrupted due
to the hurricane's impact on New York. CME US equity index futures
markets were disrupted on October 29th 2012, but reopened at 5:00pm CT.
The US equity index markets were closed from 8:15am CT on October 30,
both for the trading floor and CME Globex. The trading floor of the
NYMEX was closed on October 30, but all floor-trading products were
available electronically on CME Globex.
Source:
http://investor.cmegroup.com/investor-relations/releasedetail.cfm?ReleaseID=716923
October 2012
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
Also see:
-- http://www.chicagobusiness.com/article/20121029/NEWS01/121029818/cme-cboe-other-markets-closed-for-hurricane-sandy-about-500-local-flights-scrapped
-- http://money.cnn.com/2012/10/29/investing/hurricane-sandy-stock-markets
next_scheduled_day and previous_scheduled day should raise if
trying a return a date outside the calendar. Previously it just
returns None, but it should be made consistent with the behavior
of add_scheduled_days
Scott Sanderson