Breaks, interruptions, special market times, and min python version

[Stryder-Git]

@rsheftel, @glossner

This is my proposal for handling the interruptions marked as "NOT IMPLEMENTED" in NYSEExchangeCalendar.

Considering that these kind of "breaks" don't neatly fit into regular_market_times and/or the schedule, and that not everyone will care about them. I thought this would be a good way of optionally allowing access to the interruptions data.

The code for the 'MyCalendar' class is in this gist. There you will see the way such a property would be defined.

Demo:

cal = MyCalendar()
print(cal.interruptions_df.to_string())
                interruption_start_1        interruption_end_1      interruption_start_2        interruption_end_2
0                                                                                                                 
2011-01-10 2011-01-10 11:00:00-05:00 2011-01-10 11:01:00-05:00                       NaT                       NaT
2010-01-11 2010-01-11 11:00:00-05:00 2010-01-11 11:01:00-05:00                       NaT                       NaT
2003-09-11 2003-09-11 09:59:00-04:00 2003-09-11 10:00:00-04:00 2003-09-11 10:29:00-04:00 2003-09-11 10:30:00-04:00
2002-02-03 2002-02-03 11:00:00-05:00 2002-02-03 11:02:00-05:00                       NaT                       NaT

sched = cal.schedule("2003-09-07", "2003-09-14", interruptions= True)
print(sched.to_string())

                         market_open              market_close      interruption_start_1        interruption_end_1      interruption_start_2        interruption_end_2
2003-09-08 2003-09-08 13:30:00+00:00 2003-09-08 20:00:00+00:00                       NaT                       NaT                       NaT                       NaT
2003-09-09 2003-09-09 13:30:00+00:00 2003-09-09 20:00:00+00:00                       NaT                       NaT                       NaT                       NaT
2003-09-10 2003-09-10 13:30:00+00:00 2003-09-10 20:00:00+00:00                       NaT                       NaT                       NaT                       NaT
2003-09-11 2003-09-11 13:30:00+00:00 2003-09-11 20:00:00+00:00 2003-09-11 13:59:00+00:00 2003-09-11 14:00:00+00:00 2003-09-11 14:29:00+00:00 2003-09-11 14:30:00+00:00
2003-09-12 2003-09-12 13:30:00+00:00 2003-09-12 20:00:00+00:00                       NaT                       NaT                       NaT                       NaT

I would integrate this into the MarketCalendar base class. The .schedule method would provide an interruptions kwarg that would allow these interruptions to be added to the schedule. Then the default (not adding it) would still return the same output as the current version.

Also, it is already possible to add multiple breaks to regular_market_times and to set special times for any of those market_times. When implementing this update, I can clarify and demonstrate this further in the examples notebook.

Other changes I would like to include in this update:

• Adjust .open_at_time to work with multiple breaks and/or interruptions in a day.
• Allow offsets to be set in the special_ properties, which wasn't possible thus far.

Let me know what you think.

Additional note (mostly as a reminder to myself), offsets should also be allowed in the interruptions property.

(edit) Addtional reminder: #207

[glossner]

@Stryder-Git Looks good. Thanks!

If you enhance open_at_time(), shouldn't we enable interruptions as the default case?

[rsheftel]

Seems like a very smart solution

[Stryder-Git]

@glossner, I was planning on leaving the default as is, so that backwards compatibility is not a problem. Also, adding the interruptions will cause a lot of NaN values, that I don't think most people would want.

If there are no additional requests/issues pointed out I will get started on this in the next week or two and keep you posted.

Thanks.

[glossner]

@Stryder-Git the point about NaNs makes sense. Thanks.

[Stryder-Git]

@rsheftel, For the past weeks to months, travis kept failing with the python 3.7 build. Python 3.7 is getting relatively old and exchange_calendars is advancing its minimum python version from 3.7 to 3.8 in version 4.0. So we will have to drop 3.7 anyway and then we should also add python 3.10 to the the travis build configuration.

Unless you disagree or would like to do it yourself, should I open a PR for this before starting on the other suggestions in this issue?

Thanks.

[rsheftel]

This is released in v4.0 PR #210