True (unless you connect via Fix directly to IBs server) but ib server returns the server time which has nothing to do with your local time. It's perfectly apparent to me because I connect from a different time zone and get EST back from ib.
Could you try to be more precise in your English? It's very hard to understand what your problem is and what you try to accomplish.
I want to get the tick price with date and time, for correct charting! IB ignores the fact that between client and IB's server may be some delays and provides tick prices without date and time or provides data via RealTimeRars having a delay of 5 second (Why more 5 seconds, but not less than a second?). Because of this, I can't build correct price chart! Have you checked what do PriceTick if turn off wifi on 5 minuts? Yes PriceTick returns all data for 5 minutes at one moment. And what to do with it? IB need to change PriceTick and add date and time! It will be right!
Sure it would make the api more complete yet I still don't see what your problem is. Just time stamp the incoming locally as long as you make sure your time stamps are all converted to match the same time zone. It's not like this is hft data, those are snapshots with 200-300 ms update frequency and hence it is not relevant whether the time stamp occurs on their server side vs your local machine. It's api has much bigger issues than this so I do not see a big deal with time stamping your near real time snapshots. I would never subscribe to live updating bars.subscribe to real time data and build the bars yourself. Very simple.
Thank conduit, but 5 seconds of delay for the open session it's a big problem! Me need not more than 1 sec, it's my limit! So wiil be change me approach!
Then don't subscribe to those damn realtime updating bars. Either pull historical data or subscribe to real time data. Simple as that. The devil lies in the detail later when you really understand all the pitfalls of blending. Why you keep on talking about those 5seconds?if you build your own bars off realtime data and blend them with your historical data you request and receive then you have a perfectly fine continuous data stream. Updates of current bars come in every 200-300ms.
We have alredy talked about this above, this's IB's a bad. If IB add date-time stamp in the PriceTick (or last price) we don't have this a problem!
Real-time-data can got via PriceTick or RealTimeBar. 5sec - this is about RealTimeBar. Else we can use RTvalue as an alternative, but this's an absolute chimera of programing!
This is from the doc of API 9.72: "void reqRealTimeBars(...) Requests real time bars. Currently, only 5 seconds bars are provided. This request is subject to the same pacing as any historical data request: no more than 60 API queries in more than 600 seconds. Real time bars subscriptions are also included in the calculation of the number of Level 1 market data subscriptions allowed in an account. " Do you need sub-5s-bars? Really? As others already have suggested: build your own bars, only then can you understand the technicalities behind it...