Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

time_in_force Parameter Not Functioning as Expected with Interactive Broker and in Backtesting #576

Open
logicwar opened this issue Oct 12, 2024 · 4 comments

Comments

@logicwar
Copy link

The time_in_force parameter seems to be disregarded for both backtesting and live trading scenarios (Interactive Broker).

Regardless of the specified value (e.g., "DAY", "GTC"), all orders appear to be executed as GTC in Backtesting and as DAY in live trading (Interactive Broker).

@logicwar
Copy link
Author

Anybody facing the same behaviour or am I missing something ?

@grzesir
Copy link
Contributor

grzesir commented Oct 22, 2024 via email

@logicwar
Copy link
Author

logicwar commented Oct 29, 2024

Regarding the live trading with Interactive Broker, the issue is only for order.type set to bracket, oto or oco. These types are missing the following lines of code for main and sub-orders. These lines are implemented for the other order.types in the create_order() method of interactive_brokers.py.

            ib_order.tif = order.time_in_force.upper()
            ib_order.goodTillDate = order.good_till_date.strftime("%Y%m%d %H:%M:%S") if order.good_till_date else ""

However, as I am uncertain about the logic behind the original implementation, I am providing only an explanation of the changes I made to fix for me the issue without submitting an actual code modification. Not yet sure what the issue is when backtesting.

@logicwar
Copy link
Author

Backtesting bracket orders with time_in_force = "DAY" cannot be accurately simulated due to intraday limitations. However, partial simulation is achievable with time_in_force values such as GTC (Good ‘Til Canceled) and GTD (Good ‘Til Date). To handle these cases, I’ve modified backtesting_broker.py. Specifically, I added the following three lines in the _flatten_order() method to each order creation scenarios.

                    date_created=self.datetime,
                    time_in_force=order.time_in_force,
                    good_till_date=order.good_till_date

Additionally, in the process_pending_orders() function, I added the following lines just above the statement: asset = order.asset if order.asset.asset_type != "crypto" else (order.asset, order.quote)

# Check validity, if current date > "validity date", cancel order.
            if order.status == "unprocessed":
                if order.time_in_force == "gtd" and order.good_till_date.date() < self.datetime.date():
                    self.cancel_order(order)
                    continue
                elif order.time_in_force == "day" and self.datetime.date() > order._date_created.date():
                    self.cancel_order(order)
                    continue    

Again, as I am uncertain about the logic behind the original implementation, I am providing only an explanation of the changes I made to fix for me the issue without submitting an actual code modification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@grzesir @logicwar and others