I can't believe that the date/time format has any impact. I went with the "Date/Time in the instrument's time zone" approach a long time ago. The only major difference between our approaches is the direction of time for a sequence of requests.
I don't use historical data download that much, but I don't recall a case where a request would hang forever (in other words no historicalDataEnd() or error() callback). My client is entirely event driven and basically sends the next request upon the receipt of the previous request's historicalDataEnd() callback. Though the framework between the client and TWS API handles collecting bars and returning all bars for a request as a list of bars.
闯ü谤驳别苍
?
?
On Wed, Feb 5, 2025 at 11:03 AM, David Armour wrote:
Hi Jurgen,
?
How does that work when you get no data and no historicalDataEnd() callback? If you have no timeout then your code would just hang wouldn't it?
?
I used to download backwards, but it gave me other problems so I reversed it. I always check once I have received the historicalDataEnd() that I received the expected number of bars. So far, I have never had an error for missing bars. (I have a function to manage holidays and short trading days.)
?
I must say your delays seem long to me, but I have never checked mine other than they are all less than 15secs (based on my start latch timeout). I only ever got a timeout after 15secs with problems like the one I am facing now with QQQ. I have downloaded hundreds of symbols with long histories of 1min and 5min bars so this is not stated without some experience.
?
This is just one of those problems that IB throws at us now and again with data.
?
Going to sleep on it. May try using a different timestamp format tomorrow and see if that has any impact. Cannot really think of anything else to try.
?
?
