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)?