Welcome to the group.

Generally, the exact schedules for regular and extended trading hours are defined by the individual exchanges, so that you could implement a few functions for the exchanges you are interested in. On the other hand, a single strategy that works for any instrument is not that hard either.

The object for a given instrument (that you can and should lookup through ) gives you the native time zone for the instrument as well as the regular ("liquid") and extended trading hours for the next few days. Below a couple of examples ContractDetails objects from Thursday afternoon. Using this information has the advantage that exchange closures (regular during the weekend, for holidays, or emergency situations) are announced that way, too. It is a good practice that client applications make calls when they start or at least once a day for all instruments they deal with.

ESH5 ? timeZoneId ? ?"US/Central"
ESH5 ? tradingHours ?"20250312:1700-20250313:1600;20250313:1700-20250314:1600;20250315:CLOSED;20250316:1700-20250317:1600;20250317:1700-20250318:1600;20250318:1700-20250319:1600"
ESH5 ? liquidHours ? "20250313:0830-20250313:1600;20250314:0830-20250314:1600;20250315:CLOSED;20250316:CLOSED;20250317:0830-20250317:1600;20250318:0830-20250318:1600;20250318:1700-20250319:1600"

SPY ? ?timeZoneId ? ?"US/Eastern"
SPY ? ?tradingHours ?"20250313:0400-20250313:2000;20250314:0400-20250314:2000;20250315:CLOSED;20250316:CLOSED;20250317:0400-20250317:2000;20250318:0400-20250318:2000"
SPY ? ?liquidHours ? "20250313:0930-20250313:1600;20250314:0930-20250314:1600;20250315:CLOSED;20250316:CLOSED;20250317:0930-20250317:1600;20250318:0930-20250318:1600"

refDate ? ??????????? "20240104"
startDateTime ? ?"20240103-17:00:00"
endDateTime ? ? "20240104-16:00:00"

Each programming language has built-in or library functions to parse and compare dates and times such as Java's or to convert the resulting time into an absolute timezone free representation (such as Java's ) They bring simple tests such as IsBefore, isAfter, isBetween, ... that you an use to determine from the above data, where a given point in time for a given intrument is within the regular trading hours or bot.

Hope this helps,

闯ü谤驳别苍

?

开云体育

hey there

thanks for trying. I got the info I wanted. I'm not interested in trading it. Just using it as one of the events in a state engine I use to change my model.

??? skew_contract = Contract()
??? skew_contract.symbol = "PCUSEQTR"
??? skew_contract.secType = "IND"
??? skew_contract.exchange = "CBOE"
??? skew_contract.currency = "USD"

thanks again,

cp

I am glad this worked for you, too.

Looks like the problem and the solution is now well understood. It might be best for me to merge the two parallel topics.

闯ü谤驳别苍

Unfortunately we have two (almost identical) topics on this issue. You may want to check out "10326 OCA group revision is not allowed - it strikes again" as well.

[MODERATOR EDIT: The two topics have been merged and posts from both topics are in this topics now]

The root cause for error 10326 in that post was the fact, that the original bracket order did assign a custom OCA group name to the profit taker and stop loss child orders. Newer TWS versions seem to ignore those OCA group names, assign generic names, and consequently and correctly reject child order changes with error 10326 when the custom OCA name is used. It looks to TWS as if you want to change the OCA group membership of the order which is not allowed and causes error 10326.

As the code samples for bracket orders in the TWS API documentation suggest, do not assign OCA group names in bracket orders, rather let IBKR assign them. And when you try to change an order, always start with the last Order object you received from IBKR through an openOrder() callback. That Order object will always be most up to date and complete. And in this case, will contain the OCA group name assigned by IBKR.

闯ü谤驳别苍

Unfortunately IB does not offer this capability, to the best of my knowledge. Generally speaking, IB system does not seem to allow repricing of an order based on the execution price of another one. I guess that would introduce an additional separate layer of computational and probably legal complexity into their brokerage routine.

After you call placeOrder() for an order (or in the bracket case call it once for each of the three orders), IBKR keeps your client aware of the order progress through a variety of callbacks: openOrder(), orderStatus(), execDetails(), commissionReport(), possibly error().

The openOrder() callback provides you with an Order object that reflects all the information, IBKR has about the order. The Order object you receive in the first openOrder() callback after placeOrder(), for example, has fields such as clientId, accountId, permId, ocaGroup, ... initialized by IBKR. As the order progresses, subsequent openOrder() callbacks provide Order objects that reflect whatever change took place since the last call (quantity changes due to partial fill, trigger price changes for TRAIL orders, ....)

• makes order objects and initializes the least number of required fields when an order is initially placed (what you see as "The original bracket order" in my post)
• receives all callbacks related to the order and monitors the order progress
• maintains copies of the updated and changed Order objects it receives from time to time from IBKR )what you see in "The Profit Taker order as updated by and received from IBKR")

When it is time to make a change to an already open order (in our case the Profit Taker order), my client simply makes a call such as changeLimitPrice(). IN that case, PositionController makes a copy of the last Order object it received through openOrder(), adjusts in the copy whatever needs to be changed (in our case the limit price) and calls placeOrder() with that order object.

That approach has the advantage that I never really have to worry about what IBKR needs initialized in order for order changes to work.

Hope that makes it more clear.

闯ü谤驳别苍

?

Hi all not too familiar with IB's financial instrument lookup web approach. Normally I'd just use TWS desktop enter the ticker into a watch list ( done and working) and look at the tearsheet.

For PCUSEQTR there doesn't seem to be one. Can someone give me the link on IB's site where I can research what IB has to say about this? thanks

Works just fine for me on TWS 10.30.1u, TWS API level 173, and ESH5. Both for the IBKR default OCA type 3 as well as type 2 as you use.

What API level does your client use?

My approach is rather simple:

• I get a properly initialized Contract object for ESH5 from IBKR via reqContractDetails().
• I construct a regular bracket order with a LMT BUY entry (parent order), LMT profit taker, and STP stop loss order, and place it with the Contract object received from IBKR. The Entry order is priced at the current ask price and fills pretty much immediately. The profit and loss orders are priced 100 ticks away from the entry price (just that they do not trigger right away).
• My OrderController/TradeManager listens for openOrder() callbacks and maintains the most recent Entry, Profit, and Loss Order states and objects received from IBKR.
• 60 seconds after the entry order fills, the profit taker price is moved10 ticks closer to the entry price. This is done by changing the limit price of the most recent Profit Order object received from IBKR at that point.

Hope this helps.

闯ü谤驳别苍

?

The original bracket order:
[ {
? "orderId" : 2,
? "parentId" : 0,
? "action" : "BUY",
? "totalQuantity" : 1,
? "orderType" : "LMT",
? "lmtPrice" : 5618.75,
? "tif" : "GTC",
? "orderRef" : "Entry",
? "ocaType" : 0
}, {
? "orderId" : 3,
? "parentId" : 2,
? "action" : "SELL",
? "totalQuantity" : 1,
? "orderType" : "LMT",
? "lmtPrice" : 5643.75,
? "tif" : "GTC",
? "orderRef" : "PTaker",
? "ocaType" : 2
}, {
? "orderId" : 4,
? "parentId" : 2,
? "action" : "SELL",
? "totalQuantity" : 1,
? "orderType" : "STP",
? "auxPrice" : 5593.75,
? "tif" : "GTC",
? "orderRef" : "SLoss",
? "ocaType" : 2
} ]

The three orders in TWS:

?

The Profit Taker order as updated by and received from IBKR:

{
? "clientId" : 1741825477,
? "orderId" : 3,
? "permId" : 2088634287,
? "parentId" : 2,
? "action" : "SELL",
? "totalQuantity" : 1,
? "orderType" : "LMT",
? "lmtPrice" : 5643.75,
? "tif" : "GTC",
? "account" : "XXXXXXXX",
? "clearingIntent" : "IB",
? "ocaGroup" : "2088634286",
? "orderRef" : "PTaker",
? "ocaType" : 2,
? "transmit" : true
}