24/7 Trading Environment

1,437 views
Skip to first unread message

Rory H.R.

unread,
Jan 20, 2016, 6:29:42 PM1/20/16
to Zipline Python Opensource Backtester
Has anyone been able to implement a 24/7 trading environment? Basically, what I'd like to do is disable all calendar and time checks (yes, the what everyone worked so hard to implement).

It was partially addressed here:
https://github.com/quantopian/zipline/issues/614

Thanks,
Rory


Joe Jevnik

unread,
Jan 26, 2016, 6:21:21 PM1/26/16
to Zipline Python Opensource Backtester
We are currently working on 24/7 trading for our work with futures. I am going to ping James who might be able to give you more information about where we are with that.

Andy Visser

unread,
Mar 18, 2017, 5:46:35 PM3/18/17
to Zipline Python Opensource Backtester
Any updates on this?

fva...@quantopian.com

unread,
Mar 24, 2017, 3:26:39 PM3/24/17
to Zipline Python Opensource Backtester
Hi Rory and Andy,

We had a 24/7 calendar for futures, but we've now scaled back to 6AM-6PM.

I think the first step in having a 24/7 trading environment would be to first modify or create a new calendar that covers all 24 hours of each day.

You could take a look at the start and end times for the trading calendar here, and how we use execution_time_from_open in the futures calendar here (but this can be used for other calendars).


On Saturday, March 18, 2017 at 5:46:35 PM UTC-4, Andy Visser wrote:
Any updates on this?

Andy Visser

unread,
Apr 4, 2017, 11:17:43 AM4/4/17
to Zipline Python Opensource Backtester
Thank you very much for the info, I'll take a look into it.

Andy Visser

unread,
Apr 7, 2017, 1:59:39 PM4/7/17
to Zipline Python Opensource Backtester
I've had a chance to look at the calendar link you've sent, I should be able to set the opening and closing times, but is there a way I can have it handle the forex opening on Sundays at 5:15pm EST? I've got years of minute data, and the way it's formatted, there's an entry for every minute of every day of the year, including times when the market was closed (it just shows the last price before the close as the OHLC of every minute up until it opens again. For example, if the last price on Friday was 115.346 then every minute from then until Sunday when the market opens back up shows the Open, High, Low and Close to be 115.346. So if I can make zipline run literally 24/7, through holidays etc, then I'd expect that it could handle this csv no problem.

Again, thanks for your help, I might be getting in a little over my head here. I've made an algo with some interesting results through Neural Networks using a quick little backtest script of my own, but I'd like to run it on something a little more accurate :)

Adil Sadik

unread,
Jul 15, 2017, 6:33:17 PM7/15/17
to Zipline Python Opensource Backtester
Any luck here? I'm trying to backtest bitcoin data but I'm having trouble with a 24/7 calendar. :(

Ed Bartosh

unread,
Jul 16, 2017, 5:19:39 AM7/16/17
to Adil Sadik, Zipline Python Opensource Backtester
Hi Adil,

What kind of troubles do you have? I might be able to help if you give more details.

Regards,
Ed

--
You received this message because you are subscribed to the Google Groups "Zipline Python Opensource Backtester" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zipline+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
BR,
Ed

Adil Sadik

unread,
Jul 17, 2017, 9:17:44 PM7/17/17
to Zipline Python Opensource Backtester, spark...@gmail.com
Hey Ed, thanks! So I managed to get a 24/7 data bundle loaded by creating my own calendar file (attached.) I was able to get it working 24/7 by overriding the "day" definition and setting the open and close hours. However, when I try to run a backtest, I get this error: KeyError: Timestamp('1990-01-01 00:00:00+0000', tz='UTC'). I'm not sure why this is. I'm loading my data from a bundle I found on the internet which reads in data from a local .csv file. This data does not go all the way back to 1990, so that could be the cause of the issue, but I am not sure how to fix it. Any ideas? Thank you for taking the time to look at this!
To unsubscribe from this group and stop receiving emails from it, send an email to zipline+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
BR,
Ed
exchange_calendar_poloniex.py
stacktrace.txt

Ed Bartosh

unread,
Jul 18, 2017, 3:59:10 AM7/18/17
to Adil Sadik, Zipline Python Opensource Backtester
Hi Adil,

Your calendar looks ok. Can you point me out to the data bundle code?
Can you try to use my csvdir bundle https://github.com/quantopian/zipline/pull/1860 ?
Which zipline version do you use? If it's older than 1.1.1 I'd suggest to upgrade.

Regards,
Ed

To unsubscribe from this group and stop receiving emails from it, send an email to zipline+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
BR,
Ed

Adil Sadik

unread,
Jul 18, 2017, 8:14:15 AM7/18/17
to Zipline Python Opensource Backtester, spark...@gmail.com
Hey Ed! I've attached the bundle that I was using (poloniex.py) Note that you have to run the data fetcher before ingesting the data (PoloFetcher.py). I tried out your bundle and it looks like I'm getting the exact same error. I am running zipline 1.1.1, installed in a conda environment so my dependencies should be the right versions, too. 
PoloFetcher.py
poloniex.py

Ed Bartosh

unread,
Jul 19, 2017, 3:12:26 AM7/19/17
to Adil Sadik, Zipline Python Opensource Backtester
Hi Adil,

 I tried out your bundle and it looks like I'm getting the exact same error.
I'm getting this one when tried to ingest your data:
TypeError: unsupported operand type(s) for +: 'numpy.float64' and 'Timedelta'

Which is understandable as your data has 'date' column in the format that pandas.read_csv doesn't recognize as date.
If you can convert your data into ohlc of below form I can try to look at this further
date,open,high,low,close,volume
1996-01-02,32.25,32.25,31.75,32.13,1243700.0
1996-01-03,32.0,32.88,31.87,32.13,3837800.0
1996-01-04,32.38,32.38,31.37,31.56,2680200.0
1996-01-05,31.62,34.25,31.37,34.25,3981500.0

Regards,
Ed 


To unsubscribe from this group and stop receiving emails from it, send an email to zipline+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
BR,
Ed

Adil Sadik

unread,
Jul 21, 2017, 8:29:23 AM7/21/17
to Zipline Python Opensource Backtester, spark...@gmail.com
Hey Ed, sorry about that (and also in the delay getting back to you, busy week!) I had modified your csvdir.py file to convert the timestamps into datetime objects before pandas read them in. Instead of doing that, I've converted the timestamps in the csv files to datetimes and arranged the columns to the order that you've specified. I still get the same error :( Thank you again for taking the time to look at this! 
BTC.csv
ETH.csv

Ed Bartosh

unread,
Jul 21, 2017, 3:32:47 PM7/21/17
to Adil Sadik, Zipline Python Opensource Backtester
Hi Adil,

Looks like it breaks because default start date defined in trading_calendar module is pd.Timestamp('1990-01-01', tz='UTC').
It's possible to provide more suitable start and end dates when initializing your calendar. 

Regards,
Ed

To unsubscribe from this group and stop receiving emails from it, send an email to zipline+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
BR,
Ed

Adil Sadik

unread,
Jul 21, 2017, 7:51:59 PM7/21/17
to Zipline Python Opensource Backtester, spark...@gmail.com
Ahh that makes sense. Thank you! Do you know how I can do that? I've been searching around and haven't had much luck. Would it be in my calendar file itself?

Adil Sadik

unread,
Jul 21, 2017, 8:31:07 PM7/21/17
to Zipline Python Opensource Backtester, spark...@gmail.com
Never mind, I finally got a backtest to run (although, I am still curious if there is a better way than what I'm doing below :P) Thank you so much for your help Ed.

I found the answer in the US Futures Calendar here: https://github.com/quantopian/zipline/blob/master/zipline/utils/calendars/us_futures_calendar.py as they are overriding their start and end times as well. I had to find a suitable start date based on the data I had available in my custom calendar class (attached.)
exchange_calendar_poloniex.py

Ed Bartosh

unread,
Jul 22, 2017, 3:40:17 PM7/22/17
to Adil Sadik, Zipline Python Opensource Backtester
Hi Adil,

I was thinking about this lline in extension.py where you probably register your calendar:
register_calendar('POLONIEX', POLONIEXExchangeCalendar(start=Timestamp('2015-01-01', tz='UTC'))

This way you don't need to change calendar code and can specify different start or end times for different bundles.

Regards,
Ed

To unsubscribe from this group and stop receiving emails from it, send an email to zipline+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
BR,
Ed
Reply all
Reply to author
Forward
0 new messages