开云体育

Yes, when i try to take the options chain every call to reContractDetailsEx (with strike set to zero) lasts 1 minute instead the normal 6 seconds. I also notice that the demo program of the API (client3.exe) crash when you use "reqContractData". Can you try if you have the same problem?

thanks

--- In TWSAPI@..., "rwk2095" <r@...> wrote:

Is this still a problem? I just ran a program at 8:25 EST on 11 JUL, and everything appears normal on Globex (E6).

[rwk]



--- dairen62 <no_reply@> wrote:

hi everybody, i've a little program that that takes the chain of the options using the method reqContractDetailsEx (ActiveX). It worked fine till yesterday: every call to reqContractDetailsEx lasts 1 minute versus the 6 seconds of before yesterday. In this way the program is dramaticaly slow. Anyone experienced the same?

I transferred to IB about a month ago for the commissions. I trade futures and am disappointed with the Margin Requirement increase from Intraday to Overnight at 12:45 Pacific Time on the E-Mini's. But also on any commodities 15 minutes before the pit closes. I got slammed my first day trading because I wasn't prepared for it, but regardless it's frustrating considering how much volume and volatility there is the last 15 minutes before the bell. I didn't run into this issue with TD/Think or Swim, I also gave Trade Station a call and they don't increase the Margin Requirement's until 1:15 on the E-Mini's. IB doesn't have anything in writing on their website in regards to what time exactly they change the Margin Requirements from Intraday to Overnight, I was wondering if possibly they provide preferential treatment to certain customers... Anybody have any input?

Is this still a problem? I just ran a program at 8:25 EST on 11 JUL, and everything appears normal on Globex (E6).

[rwk]



--- dairen62 <no_reply@> wrote:

hi everybody, i've a little program that that takes the chain of the options using the method reqContractDetailsEx (ActiveX). It worked fine till yesterday: every call to reqContractDetailsEx lasts 1 minute versus the 6 seconds of before yesterday. In this way the program is dramaticaly slow. Anyone experienced the same?

Hi,

I am writing a forex scalping program with IB POSIX C++ API,

there is one question:

I need to submit one parent order and attach one trailing stop order and one profit taking order.

parent order is market order as I don't want to miss any opportunity, filling as fast as need. but trailing order can't be attached to market parent order.

if I attach a stop order first, I am not able to change it to TRAIL type later.

So what kind of solution you use?
1. submit parent order with limit order, you could put limit price higher than market price (for buy) to simulate a market order, but in this case I have to track the bid/ask as fast as I could, I don't even know IB is capable of it (no real tick price and latency between my computer and their servers).

2. submit parent order with MKT type, no child order, put a trailing order afterwards?

3. manually implement a TRAIL order by modifying stop price for STP order attached whenever necessary.


Second question,
m_pClient->placeOrder(m_orderId, m_contract, order_parent);
m_pClient->placeOrder(m_orderId + 1, m_contract, order_stoploss);
m_pClient->placeOrder(m_orderId + 2, m_contract, order_profittaking);


trying to make a MKT parent order,
and two child orders, one sl with STP type, one tp with LMT type.

problem is,

I have to submit three orders in turn. parent order first.
but after I submitt the parent order, it will be filled immediately.

child orders will produces error msg like:

Error id=59, errorCode=201, msg=Order rejected - reason:The parent order is bein
g canceled.

And another question, In TWS, I am able to submit stop with stop price of actually traded price of parent order, How should I do it via API? the trade price of parent order is unknown when submitting attached child stop loss order.

right now,
I am submitting two child orders with very wild sl and tp level and modified it once parent order gets filled. apparently this is not a good solution


Any idea?

Thanks a lot for your help!

hi everybody, i've a little program that that takes the chain of the options using the method reqContractDetailsEx (ActiveX). It worked fine till yesterday: every call to reqContractDetailsEx lasts 1 minute versus the 6 seconds of before yesterday. In this way the program is dramaticaly slow. Anyone experienced the same?

hi everybody, i've a little program that that takes the chain of the options
using the method reqContractDetailsEx (ActiveX). It worked fine till
yesterday: every call to reqContractDetailsEx lasts 1 minute versus the 6
seconds of before yesterday. In this way the program is dramaticaly slow.
Anyone experienced the same?

thanks
Enrico

I am using activex api 968 and TWS 939, that makes my data actually come all in exchange local time, not my local time anymore.

Before that I was using TWS 936 and getting times on historical in my local time, then I do not know exactly when the change happened, do not know if there was a 937, 938 version that will have the change.

Thanks


--- In TWSAPI@..., "souqmate" <souqmate@> wrote:

Pierre says the change has been since end of June, while Carlos says it comes with TWS 939. Pierre, have you changed TWS or API or java version?
I haven't observed any change, and still get my data in my local time.
I'm using TWS 939 on Ubuntu 12.0 and Java(TM) SE Runtime Environment (build 1.7.0_21-b11).
Pierre, what you call ECT is probably IB's CET; also note that Gbobex futures are in Chicago time, not NY time.
souqMate.

--- In TWSAPI@..., "pierre.dimayo" <pierrechristophe.dimayo@> wrote:

I experienced the same kind of problem. Apparently, since end of June, timestamp of the prices requested within the API are those from the exchange of the securities you are requesting the prices for, regardless of the timezone from which you are doing the request. I am in Europe and I am working mostly with stocks and future. Since I need all my prices to be at ECT I need to add +6 to the timestamp for US stocks, +1 for UK stocks -7 for Japanese stocks for example. For Globex (futures) things get weird as it appears that the timestamps for futures are 1 hour later than Eastern time. (so I have to adjust with +7). So I advise you to do some tests for each exchange you are downloading the information from and adjust accordingly by comparing to the previous data you have.

I had a quick chat with the helpdesk who confirmed the change in the timestamps and it seems that this change will be permanent.

Cheers

Pierre

--- In TWSAPI@..., "Carlos" <ctalmeida@> wrote:

I have been downloading historical data from IB for years.
I never use the timezone on the request.
I always received the data date and time of the local computer.
Then if my windows is set for Pacific Time I received 1 minute bars for IBM starting 6:30 until 13:00.

Yesterday I update my TWS to the 939 version with API 9.68
Now same data request comes in EDT time, that is same data request now comes with time from 9:30 to 16:00. If I install back the TWS 936 I get back what I had in the past 6:30 to 13:00.

I can change my code and make all work but is there a mistake somewhere from IB that they will revert back in the future or this is how will be from now on? Anyone has information on this?

BTW I did try with FOREX EUR/USD and the same in the past historical data would come with my local computer time and now it comes in EDT.

Thanks for any information.

--- In TWSAPI@..., "Robert" <robertrackl@> wrote:

My policy is to keep time internally in UTC (=Zulu=GMT). Conversion to/from local time takes place only when user interaction is required. This way you don't worry about clocks getting set forward or backward.

--- In TWSAPI@..., "btw12342001" <newguy@> wrote:

You don't have to specify a time zone. I just do the request and ask for a unix timestamp by specifying 2 in the last field. Then you don't need timezones. If you want it in local time then just use the date class to put the unix time automatically into the right EST or EDT.

For those syncing clocks, don't you worry about having a later tick arrive with an earlier time if your clock gets set backwards? There is a way to do this properly in the win32 API but it's complicated. You can read further starting here
(v=vs.85).aspx



--- In TWSAPI@..., "pier3846" <hf-trader@> wrote:

Hello all,

I am having troubles with timezones when requesting for historical data with the Java API.

The API guide provides a list of supported timezones:



1) This list seems to be incomplete as CET seems to be also supported.

2) More important, I can see that EDT is not supported therefore I wonder what is IB's definition of EST. Specifically, I wonder whether IB's definition of "EST" encompasses "EDT" too. In other terms, do they use "EST" all the year, even during summer time? Or is "EST" really the "EST" timezone, with a shift of one hour compared to EDT, as those timezones are defined in Java, for instance.

I do not find much information on this topic. Anyone has an experience with timezones and the TWS API?

Thanks!!

Pierre

Did they add a new multiplier today?

The same thing happenned with stock options when mini options were
introduced for higher-priced stocks several months ago.

-Kurt


On 7/10/13 5:42 AM, "Davqe" <drosen@...> wrote:

This morning I received the error that my contract specification for Silver
was ambiguous because I did not specify the multiplier. Is this new? I was
able to run the same program last night at 9am with no problems.

This morning I received the error that my contract specification for Silver
was ambiguous because I did not specify the multiplier. Is this new? I was
able to run the same program last night at 9am with no problems.

Eugene,

On 6/28/13 8:34 AM, "Eugene" <evlap1@...> wrote:

Thanks Kurt for the detailed post.

I can't use market data for daily high/low since when I invoke reqMarketData
after day's close high/low will refer to the new day already. And having
market data channel open during the day isn't feasible due to the high number
of contracts I'm interested in.

Ah, ok, I guess that's a futures thing, with the trading being more
continuous.

My understanding is that settlement price always exists; even if no trades had
occurred during the day. That's the reason I thought I'd need it.

The bid and ask (and therefore midpoint) always exist too, FWIW. (Well with
stock options there may be gaps or ultra-wide spreads at times but it tends
to converge as the day progresses.) I suppose it could be argued that
bid/ask without trades might also fail to be indicative, but it still
strikes me as more real.

At one point I tried to find information on the CBOE website about how they
determined their settlement price, but there was no clear information. And
I saw the settlement be whacky on many occasions. This even screwed up my
manual trading decisions a few times (thinking of it as "close") until I was
savvy to it. Again this was for US stock options. Perhaps it is different
with futures. And maybe better information is available for futures options
than stock options.

I want to
have some representative price for every contract. I believe this is what
TickType=CLOSE refers to.

Yes, but have you looked at it and determined it is reasonable?

There was something I saw in a quick skim just now that suggests to me that
the settlement price might be based on the day's opening, which might
explain some of what I saw. I haven't looked into this further yet.

So if I decide to incorporate historical trades data
into my database I might need to have fields for OHLC and Settlement prices.
I'm still trying to figure this out...

It might be useful to track where the trades fall in relation to the
bid/ask.

OHLC are nice to have to get an idea about price changes during the day but
less critical for my need. I'm mainly interested in tracking day-to-day price
changes.

Weighted average might also be useful. It also occurs to me that something
like the reciprocal of the bid/ask spread might be an indication of how
authoritative the values are, and if you were to track them during the day a
bid/ask average based weighted by the tightness of the spread might produce
some interesting end-of-day indication, possibly even with an EOD trend
target. I wonder how the settlement prices are arrived at. And if they are
only used in relation to exercise then ... well draw your own conclusion.

-Kurt

I found a bunch of old discussions on building historical bars - will go thru
them to fish for other ideas.

--- In TWSAPI@..., Kurt Bigler <kkb@> wrote:

What rwk said aside, if you are going to use market data to get "close" do
you have any reason not to use market data to get the daily high and low,
maybe even the open?

I believe there have been complaints about the open quote not being reliable
or consistent, and I'm not sure which of the various possible methods yield
better results, but I think this has been discussed in the last several
months.

Regarding "settlement price", I don't know about options on futures, but for
options on stocks the settlement price can be next to nonsense, having
sometimes questionable relationship to prices traded that day, never mind
not being anywhere near the last price traded. I can't see why settlement
price is of any use to anyone. I also brought that up here a year or two
ago and think I got some agreement. To fit an OHLC bar I would think the
settlement price is the last thing you want, unless it is more sensible in
relation to futures than to stocks.

So another option might be to take the open from the first hour bar, and the
close from the last hour bar, and the high/low from the quotes after the day
closes.

Or you could conceivably sample the open/close yourself from the quote
stream. IB's sampling will interfere with accuracy but I believe someone
had suggested a reason why such an approach might be preferable, which is
referring back to the thread I recall from the last several months.

-Kurt


On 6/26/13 7:27 AM, "Eugene" <evlap1@> wrote:

Hello forum,

I'm trying to come up with a strategy to construct OHLC EOD data for options
on futures. My problem is that option historical data doesn't exist as day
bars so I have to work with hour bars.

My plan is to use historical 1-hour trades bars to get OHL and use market
data
that I invoke after US close hours to get reliable close (settlement) level.

Can anybody think of a better approach? Any feedback will be appreciated.

I am using activex api 968 and TWS 939, that makes my data actually
come all in exchange local time, not my local time anymore.

Before that I was using TWS 936 and getting times on historical in my
local time, then I do not know exactly when the change happened, do
not know if there was a 937, 938 version that will have the change.

Thanks

--- In TWSAPI@... <mailto:TWSAPI%40yahoogroups.com>,
"souqmate" <souqmate@...> wrote:

Pierre says the change has been since end of June, while Carlos says

it comes with TWS 939. Pierre, have you changed TWS or API or java
version?

I haven't observed any change, and still get my data in my local time.
I'm using TWS 939 on Ubuntu 12.0 and Java(TM) SE Runtime Environment

(build 1.7.0_21-b11).

Pierre, what you call ECT is probably IB's CET; also note that

Gbobex futures are in Chicago time, not NY time.

souqMate.

--- In TWSAPI@... <mailto:TWSAPI%40yahoogroups.com>,

"pierre.dimayo" <pierrechristophe.dimayo@> wrote:

I experienced the same kind of problem. Apparently, since end of

June, timestamp of the prices requested within the API are those from
the exchange of the securities you are requesting the prices for,
regardless of the timezone from which you are doing the request. I am
in Europe and I am working mostly with stocks and future. Since I need
all my prices to be at ECT I need to add +6 to the timestamp for US
stocks, +1 for UK stocks -7 for Japanese stocks for example. For
Globex (futures) things get weird as it appears that the timestamps
for futures are 1 hour later than Eastern time. (so I have to adjust
with +7). So I advise you to do some tests for each exchange you are
downloading the information from and adjust accordingly by comparing
to the previous data you have.

I had a quick chat with the helpdesk who confirmed the change in

the timestamps and it seems that this change will be permanent.

Cheers

Pierre

--- In TWSAPI@... <mailto:TWSAPI%40yahoogroups.com>,

"Carlos" <ctalmeida@> wrote:

I have been downloading historical data from IB for years.
I never use the timezone on the request.
I always received the data date and time of the local computer.
Then if my windows is set for Pacific Time I received 1 minute

bars for IBM starting 6:30 until 13:00.

Yesterday I update my TWS to the 939 version with API 9.68
Now same data request comes in EDT time, that is same data

request now comes with time from 9:30 to 16:00. If I install back the
TWS 936 I get back what I had in the past 6:30 to 13:00.

I can change my code and make all work but is there a mistake

somewhere from IB that they will revert back in the future or this is
how will be from now on? Anyone has information on this?

BTW I did try with FOREX EUR/USD and the same in the past

historical data would come with my local computer time and now it
comes in EDT.

Thanks for any information.

--- In TWSAPI@... <mailto:TWSAPI%40yahoogroups.com>,

"Robert" <robertrackl@> wrote:

My policy is to keep time internally in UTC (=Zulu=GMT).

Conversion to/from local time takes place only when user interaction
is required. This way you don't worry about clocks getting set forward
or backward.

--- In TWSAPI@...

<mailto:TWSAPI%40yahoogroups.com>, "btw12342001" <newguy@> wrote:

You don't have to specify a time zone. I just do the request

and ask for a unix timestamp by specifying 2 in the last field. Then
you don't need timezones. If you want it in local time then just use
the date class to put the unix time automatically into the right EST
or EDT.

For those syncing clocks, don't you worry about having a

later tick arrive with an earlier time if your clock gets set
backwards? There is a way to do this properly in the win32 API but
it's complicated. You can read further starting here

(v=vs.85).aspx

--- In TWSAPI@...

<mailto:TWSAPI%40yahoogroups.com>, "pier3846" <hf-trader@> wrote:

Hello all,

I am having troubles with timezones when requesting for

historical data with the Java API.

The API guide provides a list of supported timezones:

1) This list seems to be incomplete as CET seems to be

also supported.

2) More important, I can see that EDT is not supported

therefore I wonder what is IB's definition of EST. Specifically, I
wonder whether IB's definition of "EST" encompasses "EDT" too. In
other terms, do they use "EST" all the year, even during summer time?
Or is "EST" really the "EST" timezone, with a shift of one hour
compared to EDT, as those timezones are defined in Java, for instance.

I do not find much information on this topic. Anyone has

an experience with timezones and the TWS API?

Thanks!!

Pierre

Pierre says the change has been since end of June, while Carlos says it comes with TWS 939. Pierre, have you changed TWS or API or java version?
I haven't observed any change, and still get my data in my local time.
I'm using TWS 939 on Ubuntu 12.0 and Java(TM) SE Runtime Environment (build 1.7.0_21-b11).
Pierre, what you call ECT is probably IB's CET; also note that Gbobex futures are in Chicago time, not NY time.
souqMate.

--- In TWSAPI@..., "pierre.dimayo" <pierrechristophe.dimayo@> wrote:

I experienced the same kind of problem. Apparently, since end of June, timestamp of the prices requested within the API are those from the exchange of the securities you are requesting the prices for, regardless of the timezone from which you are doing the request. I am in Europe and I am working mostly with stocks and future. Since I need all my prices to be at ECT I need to add +6 to the timestamp for US stocks, +1 for UK stocks -7 for Japanese stocks for example. For Globex (futures) things get weird as it appears that the timestamps for futures are 1 hour later than Eastern time. (so I have to adjust with +7). So I advise you to do some tests for each exchange you are downloading the information from and adjust accordingly by comparing to the previous data you have.

I had a quick chat with the helpdesk who confirmed the change in the timestamps and it seems that this change will be permanent.

Cheers

Pierre

--- In TWSAPI@..., "Carlos" <ctalmeida@> wrote:

I have been downloading historical data from IB for years.
I never use the timezone on the request.
I always received the data date and time of the local computer.
Then if my windows is set for Pacific Time I received 1 minute bars for IBM starting 6:30 until 13:00.

Yesterday I update my TWS to the 939 version with API 9.68
Now same data request comes in EDT time, that is same data request now comes with time from 9:30 to 16:00. If I install back the TWS 936 I get back what I had in the past 6:30 to 13:00.

I can change my code and make all work but is there a mistake somewhere from IB that they will revert back in the future or this is how will be from now on? Anyone has information on this?

BTW I did try with FOREX EUR/USD and the same in the past historical data would come with my local computer time and now it comes in EDT.

Thanks for any information.

--- In TWSAPI@..., "Robert" <robertrackl@> wrote:

My policy is to keep time internally in UTC (=Zulu=GMT). Conversion to/from local time takes place only when user interaction is required. This way you don't worry about clocks getting set forward or backward.

--- In TWSAPI@..., "btw12342001" <newguy@> wrote:

You don't have to specify a time zone. I just do the request and ask for a unix timestamp by specifying 2 in the last field. Then you don't need timezones. If you want it in local time then just use the date class to put the unix time automatically into the right EST or EDT.

For those syncing clocks, don't you worry about having a later tick arrive with an earlier time if your clock gets set backwards? There is a way to do this properly in the win32 API but it's complicated. You can read further starting here
(v=vs.85).aspx



--- In TWSAPI@..., "pier3846" <hf-trader@> wrote:

Hello all,

I am having troubles with timezones when requesting for historical data with the Java API.

The API guide provides a list of supported timezones:



1) This list seems to be incomplete as CET seems to be also supported.

2) More important, I can see that EDT is not supported therefore I wonder what is IB's definition of EST. Specifically, I wonder whether IB's definition of "EST" encompasses "EDT" too. In other terms, do they use "EST" all the year, even during summer time? Or is "EST" really the "EST" timezone, with a shift of one hour compared to EDT, as those timezones are defined in Java, for instance.

I do not find much information on this topic. Anyone has an experience with timezones and the TWS API?

Thanks!!

Pierre