开云体育

Thanks Nick, dealing with dozens of different futures/regions, so I would rather avoid hardcoding anything. The way I see it is: * get current month in whatever timezone you are * subtract 1 month to

It's true that different futures have different rollover dates but there are accepted days for doing the rollover so you don't have to guess. If you're not trading 100's of different contracts it's

Thanks Jürgen, had a good read and tested several of these options. In short, there is no easy way to algorithmically pull the current most liquid future contract in all situations, which is what

One small correction to your calculation, Gordon. If you were to boost your account to 1,100 market lines, you would be able to receive streaming BID, ASK, and TRADES for 1,100 instruments. Not just

I basically moved to polygon.io for all my data. I don't get anything from IBKR anymore, even for live trading. It just isn't worth the headache to use IBKR for anything like this because at the end

I am trying to gather a large amount of data, and running into pacing violations, data line limits, etc. ?I will describe below what I am trying to accomplish, and the various things I have tried

Is there a way to automate retrieving margin report? Like the following example,?https://www.interactivebrokers.co.uk/images/common/Statements/marginreportportfoliomargin.html

This works Great - Thanks! I knew there had to be a way, otherwise how could one possibly share spreadsheets with others if they had to constantly be worrying about what version of the API the other

There is a way, but it involves rebuilding the TWSLib.dll with a different type library identifier. If you're happy working with Visual Studio, and you happen to have the source code for version

I want to run an ActiveX spreadsheet developed using API_Version=9.81.01 on a computer that has API_Version 10 installed. If I copy the CSharpAPI files TWSLIb.dll and the two tlb files to a directory

I am a little rusty with the with the IB API and programming for that matter. I’ve had a working program for many years now and have had no need to meddle. I’ll try the longer time zone string as

I should have been a little more precise, Mark. For many years, Java has used the TZ Database ( https://en.wikipedia.org/wiki/Tz_database#Definition_of_a_time_zone ) as the source for time zone

I have been using the string format yyyymmdd hh:mm:ss xxx with ‘AET’ successfully for over ten years. This is the error message I get when using ‘AET’ time zone with TWS 981. The date, time,

Take a look at the time zone field in the ContractDetails object for a locally listed instrument, Mark. For a while now, TWS mostly uses modern Java style time zone names instead of the short legacy

Since upgrading from tws 975 to tws 981 GTD orders are getting rejected for the time-zone “AET” ‘The date, time, or time-zone entered is invalid.’ GTD orders work fine with all time zones I

I am not saying it is not happening, I am just saying we have not experienced it. But then we look mostly at highly liquid futures in the US. Since your TWS API log shows your issue, maybe you should

The delay is obvious when monitoring tickprice in tws log.for tickprices. swedish ”national” exchange. Before my code..

My experience is the same as Jürgen's: the high is updated pretty much immediately (ie within a millisecond). This has been the case for the past 18 years that I've been using the API. If you are

The delay of updating HIGH can be 5-10 seconds, why delayed?

If you do not specify time zones, local timezone refers to the time zone your TWS or IBGW uses. And that can be selected or checked, for example, in the "More Options" section on the login