Monthly Liquidate - EOM issue

[DirkFR]

The monthlyLiquidateRebalanceStrategy has an issue with the _end_of_month() function.

the statement end_day = calendar.monthrange(cur_time.year, cur_time.month)[1]will miss any month where the last day of the month is not a trading day. Taking the example of AGG, it would have missed July 2016 completely, since the last trading day was 29.07. while EOM was 31.07.

So the way I understand (or not understand, maybe it´s my issue) it, _end_of_month()only fires if the last trading day of the month is equal to the last day of the month. A possible fix would be to trigger on the first day of the new month, comparing the current event's month with the month in the last event (if change, then new month).

What do you think? Should we build a more robust trading calendar functionality?

[nwillemse]

I also ran into this issue a while ago. Currently as a quick solution I have the days listed in a file that gets read during startup and the logic is based on that.

However, recently I ran into this trading calendar package. I haven't used it yet (I think it only supports python3).

http://pandas-market-calendars.readthedocs.io/en/latest/index.html

[femtotrader]

Quantopian zipline have market calendars See https://github.com/quantopian/zipline/tree/master/zipline/utils/calendars (pandas_market_calendars code seems to be taken from zipline)

Anyway this could be worth to be a separate project.

Pinging @rsheftel (pandas_market_calendars author) and @quantopian ( @ehebert @jbredeche )

[mhallsmoore]

@DirkFR - Thanks for pointing this out! It is definitely unanticipated behaviour, so I will classify this as a bug.

@nwillemse - This is a good idea. I'll take a look at this over the next couple of weeks and see if it will fit the bill.

When I was previously at a small fund we kept track of all US trading days/holidays for the duration of our backtests. It was continuously updated for the future when such information became available.

I'm a bit concerned that we may need quite a sophisticated solution for this, as we don't want to become too US-centric, given that others may want to algo trade outside of US equities!

For instance, a proper backtester will eventually have to incorporate periods where trading was not permitted, despite being a valid trading day. E.g. "circuit breaking" and "flash crashes".

[rsheftel]

Hello, its the author of pandas_market_calendars . I created this package because I had the exact needs you guys seem to have which was my motivation for creating it. I forked the code from the zipline project because their implementation was heavily interwoven with the entire zipline project, so I just pulled out the most essential pieces to keep this package lightweight.

The goal is a standard package for all global exchanges, OTC products, and allow holidays even by specific futures contracts (for example on the CME different contracts have different holidays or early-closes). Something similar to pytz for time zones, a single go-to package.

It would be great to work with you guys to make the package usable for both of our needs, that would keep more eyes on it and increase the reliability and completeness.

As for the Python3, I only cared about python 3 so I tested it on that, I don't think there is anything major in here that would prevent it from running on python 2, and if so it would probably be a small change to make it work on both 2 and 3.

[rsheftel]

If you guys are still interested in the pandas_market_calendars it has been updated to support Python 2.7 in addition to Python3 now.