Apologies for the rant, but.... As IB API users would be aware, execution reports come with a m_time field which indicates the execution time as a String in "yyyyMMdd HH:mm:ss" format. I've always received times based on America/New_York time zone, but wanted to confirm with IB (since the docs helpfully say only "The order execution time") to ensure it wasn't based on product etc. First response: Uh, no you don't. So I provide them with actual execution samples and show the EDT time reported. Next response: What? Didn't you just categorically tell me it's always GMT? Next response: Let's be clear here: IB are sending a string down a socket from TWS/Gateway. Any conversion that is taking place is taking place inside their software, yet somehow I'm supposed to understand what happens internally in TWS. After pointing out that their own TWS logs show the EDT timestamp: So, when they said they report in GMT to all users always, they actually meant they send GMT times down the encrypted SSL connection from their servers to TWS....because clearly that's what's relevant to the user...but no: Amazingly, they're still insisting that the m_exec string value is in GMT. After pointing out again that this a string that is sent from their application down a socket and it is impossible for it to be "converted" on the client side, I get this: So, what they now seem to be saying is that it might be GMT, it might be local system time. They simply don't know because it's "Java's" fault. Absurd. And apparently, receiving the execution time in a format where you have some idea about what the time actually is, is a feature. A feature that isn't implemented, but if I submit a feature request, might be considered. I think the reality is that it's being converted to the zone of the JVM running TWS/Gateway and support don't know what they're talking about. Does anyone have any indications that this is not the case (i.e. getting reports in zone other than JVM)?
I had a brief chat with them on last week about a similar issue, my question was regarding whether they differentiated EDT from EST. Their answer was essentially whatever TZ your system is reporting, then that is the time reported. I suppose this could be verified just by changing the system TZ.
yeah if it's raymund (api@ib), he doesn't know jack about programming and as far as I can tell his purpose is primarily to prevent programmers from having to deal with clients. still he doesn't really know anything so (perhaps not unsurprisingly) he doesn't seem to get support from his own team. if you are sympathetic to this and persistent you can get him to do stuff, but it's generally less effort to find work arounds.
No, it's "Angel", although there were no names after the first categorical message of "it is always GMT". The most ridiculous part of this is that there were almost 20 messages back and forth without a correct answer being provided. One wonders just how much money IB waste on support staff when a one line description in the API reference would have removed the need to even contact them. Or a simple correct response of "It's based on TWS JVM time zone". Instead they suggest I request a new feature!
If you are that smart, developing algos on ib tws, then you realize that the executing/order time is based on your computer settings, not the application or market's time, because it simply doesnt know. Say im in Singapore and I trade US stocks, I have to adjust 12 hrs, Japan asian trading is 1 hour less SG, adjust to that, as well as other markets like Gold and Oil, depending on whicgh exchnge it is in. Perhaps you should try out more of IB order function eg. accumulate or dsitribute function and u might udnerstand. Wasted my 3 mins.
What doesn't know? There is an SSL connection from IB's server to TWS and an open local socket between TWS and your client app. Suggesting that there is no possibility that a string being sent down the local socket is being transmitted from the server side shows you don't actually understand the mechanics behind IB's setup. If you have ever done any serious development work, you will understand that there is a significant difference between a specification and an implementation. Simply testing something and checking the result does nothing to guarantee that the behavior is a result of something that can be relied upon and won't change due to any number of possible factors. Given my production machine in in NY time zone, it also doesn't tell me whether the time is being converted locally, at the server side, or not at all. Even if showed that it's being converted locally, that wouldn't indicate whether it is done based on the TWS JVM time zone, the time zone of the JVM the client API code is running in, or some other method. Not understanding how changes in these factors will affect your system is a recipe for disaster down the road. It also doesn't show whether trades on exchanges in different time zones will report differently. Are you are seriously suggesting changing each factor and executing live trades just to see what happens? The paper account is not useful since it's behavior regularly differs from live trading. This is the purpose of an API. It is a contract that specifies behavior that is guaranteed. Unfortunately IB failed to document their API fully and instead require developers to poll their support or third parties for answers. The purpose of the post was highlight the complete lack of understanding that the front-line support staff have with respect to the API. It reflects poor training which in turn implies poor management. One hopes that a sufficient level of public attention might encourage improvement.
yada yada yada.... no wonder the IB support staff gave u funny answers, cos u asked alot of funny questions. I've no problem with trading different markets at different times, Mind u im From Singapore and I have to adjust my code twice every yr all thanks to US daylight saving, and the differences tha affected between US and other country markets. THere's a reason for the IB TWS paper trade acct. I don't see how it differents for the live ones, if you want to test your codes. Yes i agree IB failed to document their API, in the first place IB is not a SW development company. They dont make money selling APIs. If you are smart so you should know they don't spend resources writing documentations help or answering you too much..