Allow users to change start_default/end_default in trading_calendars

[leonarduschen]

Related to the issue: quantopian/zipline#2700

As @richafrank mentioned on the issue linked above is the module-level variable start_default in trading_calendars\trading_calendar.py being '1990-01-01'.

In my opinion '1990-01-01' seems somewhat arbitrary. As far as my understanding goes, the only reason it is '1990-01-01' and not earlier is to avoid caches to take up too much memory.

Disadvantages of this approach:

• The open-issue linked above
• PrecomputedTradingCalendar uses its own start/end dates and some of them start earlier than '1990-01-01'
• The cached data frame does not take that much memory anyway? (but I might be utterly wrong here)

Possible solutions off the top of my head:

• Change 'start_default' to something much earlier
• Add exchange specific start_default and end_default, this is consistent with how PrecomputedTradingCalendar behaves
• Add a way for end-user to change start_default and end_default (e.g. store start_default and end_default in a mutable container than give access to end-user).

[gerrymanoim]

Thanks for opening this - let me do some digging.

[Laurentvw]

I second this. Let me add some weight to this.

I am using some assets that go as far back as the 1870s. The get_calendar() utility method currently doesn't allow me to set an earlier default date.

So I resort to doing something like this:

from trading_calendars.exchange_calendar_xams import XAMSExchangeCalendar
start = pd.Timestamp(from_date, tz=pytz.UTC)
tcal = XAMSExchangeCalendar(start=start)

Having a way to change the default dates from the get_calendar() utility would come in handy.

[gerrymanoim]

Cool to hear you're working with asset data that goes back that far!

I think passing an optional start date param via get_calendar makes sense to me, rather than messing with the defaults. @richafrank - what do you think?