Join the 80,000 other DTN customers who enjoy the fastest, most reliable data available. There is no better value than DTN!

(Move your cursor to this area to pause scrolling)

"IQ feed is brilliant. The support is mind-bending. What service!" - Comment from Public Forum Post
"For anyone considering using DTN.IQ for a data feed, my experience with the quality of data and the tech support has been very positive." - Comment from Public Forum
"I just wanted to let you know how fast and easy I found it to integrate IQFeed into our existing Java code using your JNI client. In my experience, such things almost never go so smoothly - great job!" - Comment from Nate
"My broker in Davenport suggested I give you a try as he uses your service and says its the best." - Comment from Bill via RT Chat
"Everything is working amazing now. I'm already impressed with the true-tick feed of IQFeed and it's ability to support my 480 symbol layout." - Comment from Tyler via Email
"I used to have *******, but they are way more money for the same thing. I have had no probs with data from DTN since switching over." - Comment from Public Forum Post
"Thank you so much - awesome feed, awesome service!" - Comment from Greg via Email
"I'm very glad I switched to IQFeed. It's working perfectly with no lag, even during fast market conditions." - Comment from Andy via Email
"If someone needs the best quality data and backfill beyond what their broker provides at a rate that is the best in the industry, I highly recommend IQFeed." - Comment from Josh via Public Forum
"Interactive Brokers tick data was inconsistent, so I have switched to using DTN exclusively. It is great to no longer have to worry about my datafeed all day long." - Comment from Philippe
Home  Search  Register  Login  Recent Posts

Information on DTN's Industries:
DTN Oil & Gas | DTN Trading | DTN Agriculture | DTN Weather
Follow DTNMarkets on Twitter
DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter
Viewing User Profile for: redblue
About Contact
Joined: Oct 29, 2009 05:19 PM
Last Post: Nov 5, 2015 03:18 AM
Last Visit: Nov 5, 2015 03:18 AM
Yahoo IM:
Post Statistics
redblue has contributed to 51 posts out of 21085 total posts (0.24%) in 5,082 days (0.01 posts per day).

20 Most recent posts:

Thanks Tim.

I assume the same happens with the live feed (EST/EDT)?


Thanks Tim for quick reply.

Ok. So what does "EST as is appropriate" actually mean? For example:

We're now in EST until 13 Mar 2016, 02:00. What happens after that time? Do you adjust the new bars to 'become' EST as the new data generated wont be in EST but EDT? In other words, is the datetime always the same time away from UTC?

Or, are you saying that the data is actually in EST and when daylight savings is in effect, the data is in EDT. So this would mean for each year, is half the dataset in UTC-5 and the other half UTC-4?

(the reason why this is important is that we're looking at instruments that trade 24 hours a day and we're seeing differences in the historical dataset coming from IQfeed and the broker).


I'll admit I am very confused, so please excuse the silly questions, but I need to start with the basics...:)

I need to convert all historical and streaming data into UTC.

I understand that all historical data is in EST. To convert this time to UTC, I just need to add 5 hours. However, is this *always* correct with daylight savings? In other words, if I request a months worth (from now) of historical data (say hour bars), do I just add 5 hours to the date time for *all* bars, even though this requests spans a switch from summer time?

Likewise, is the live streaming always in EST, so I'd just need to add 5 hours or does it change to EDT for daylight saving?


]Alternatively, we build our daily bar for history at the close, 17:15, using this same logic throughout the afternoon, so you can wait and just pull that bar and save yourself the trouble. I will verify how long it can take for that bar to propegate throughout our systems and let you know.]

Thanks, this would be good to know. On a related topic, what happens if you don't get a settle before 17:15?

[As to the other symbols, were you watching for P messages as well as U messages for the update? I show settles came through between 5:10 and 5:20 for the first few contracts of each of these on the 21st.]

Arh, that could be the piece we're missing. We're currently only looking on Q messages (for the settle change), we'll start looking at the P messages as well (U message, what's that?).

[I am not sure how you could get a new high or low when the market is closed. I have not seen this personally. What conditions did he say would cause the high and low to be set while trading is closed?]

The market isn't closed...

For ES (EST times):

settle at 16:15
close at 17:15

So, yeah, the high and low can be set after the settle price (close).

Just to clarify some times:


For ES:
settle at 15:15
close at 16:15

the session high low can be set between 15:30 and 16:15

Hi Tim,

Thanks for the reply. Question, do you know why we wouldn't get settlement for those two other symbols?

Just to clarify, we're trying to get the OHLC values for the previous exchange traded day bar before the market opens again at 17:00.

Regarding @ES, our understanding (which has been confirmed from someone from CME E-quotes supports) is that:

The High and Low of the session can happen after settlement which is why we are watching for those values. In other words:

Settle at 3.15
but the High and Low can be set between 3.30 and 4.15.

Which is why we can't just watch the settle date change. Does that make sense to you guys (or is the CME guy wrong)?

If we abandon this tick approach, and go for a historical pull do you know how/when your daily data is updated?

Hi Guys,

Sorry to resurrect this thread, but we're really struggling to make sense of what we're seeing with the feed. Hopefully it's something we're not understanding or doing wrong.

What we need:

To build an OHLC bar that matches the official day exchange bar for a collection of futures and get this *before* the market options.

An example:

ES, closes at: 4:15pm, and we want to get this bar before 5.00pm when the market opens again.

What we have done:

We've attempted to get this from a live tick stream using the following fields:

"S,SELECT UPDATE FIELDS,Symbol,Last,Incremental Volume,Bid,Ask,Bid Size,Ask Size,Last Trade Time,TickID,Settlement Date,Open,High,Low,Close,Settle,Last Trade Date,Total Volume\r\n"

Then placing various 'watches' on the tick stream for things like settlement date changes, and looking at the Open,High,Low fields when the market closes. We do the watch for the close so we can capture any change to the High and Low prices after the settle.

Which leads to the first question, is this approach valid (we wanted to get the data in the tick stream)? Or should we do a historical daily fetch when the market closes/ just before the market opens?

What we have seen (for Friday the 21st):

We didn't get any settlement changes for @US# or @EU#, so we couldn't work out the official close.

Any thoughts on what other approaches should we use?



We've done some testing on the approach mentioned in this thread (watching the settlement date for a change), but we're a little confused to the time it changes:

Symbol,time EST (and ticktype),Settlement Date,Day Open,Day High,Day Low,Day Close,Last Trade Date,


Why would it change at 16:30 and not at 17:15?


Thanks Tim.

Do you know if there is any way to find out how often there is a 'delay' in settle?


Thanks for the clarification.

Sorry for more questions:

Is there any intra-day bar based fetch we can do that will get us bars that have these Form T trades excluded (again, so we can build EOD bars and match the exchange from intra day data).

Do you know when the exchange day bar is available (for futures)? If we pull it (say) 5 minutes after close, would the data be available?



Just to clarify a few things.

We can understand why the close would be different as there some logic that happens at the exchange but we're a little confused about the open. Wouldn't the open just be the fist tick?

Another question, when you say "T trades", do you mean trades that aren't electronic, but end up getting included into the feed and in the case of your (intra-day) bar data they are included?


Ok, so if I had this pseudo logic:

if (tick->type == C) {
include the tick in calculating the OHLC for the day;

would this end up matching the exchange day?

Thanks for the reply.

Can the T trades be filtered out at the tick level?

Hi Steve,

Thanks for the reply. Yeah, we'll be able to get the session hours externally.

I've just been looking at the 1 minute bars for @ES# and comparing them to the daily bars, and in some cases I can't seem to match them up. Do you know why?

For example, for the 12th of February 2014:

Daily Bars:

Open = 1813.25
Close = 18.17

Which seems to match other sources

For 1 minute bars, I see (again from IQfeed):

11th Feb 17:00, Open = 1812.75
12th Feb 16:15, Close = 1817.25

Other bars seem fine, while others seem a point or so out. Thoughts?



I am trying to build daily bars from the tick stream that match the 'exchange' daily bar. The problem is with instruments that don't have a typical day, such as various futures. For example, for ES, the open is at 17.00 the previous day.

The problem is that I can't seem to find any information about the opening time/closing time of a particular instrument? Can this data be retrieved from the feed? Something like below:

I've done some basic testing and it seems that IQfeed's daily bars do seem to match the exchange (for @ES# at least) is there any documentation describing how IQfeed create these daily bars?


IQFeed Developer Support » IQFeed freezes Apr 14, 2011 11:55 AM (Total replies: 9)

Yes, we've had more cases of this today - for some reason IQConnect starts in a disconnect state. The end user has to manually connect. Is there any way around this problem?

IQFeed Developer Support » IQFeed freezes Apr 6, 2011 04:34 AM (Total replies: 9)

Ok, some more information...

What ever we have done within our application has made things worse:) The end user is now getting these freezes almost every time in his 15 minute cycle...

On a more positive note, I dont think IQFeed is the problem but our app. For what ever reason, IQFeed is running but not in a connected state. If the end user simply clicks on "Start Feed" then data flows correctly into the app (with no interaction from our app). Is it possible for IQfeed to start up, log in and not be in a connected state?

As a side, I've had a play with trying to send "S,CONNECT\r\n" (every second) when the IQFeed status is "Not Connected" and this will cause IQFeed to crash (after 30 seconds or so). If you need the exact steps to reproduce let me know.



IQFeed Developer Support » IQFeed freezes Apr 4, 2011 03:53 PM (Total replies: 9)

Yes, our app is restarting every 15 minutes and IQfeed also restarts (which is fine, just that IQfeed freezes now and again).

Ok, I will change our code to close the L1 connections and not bother with the DISCONNECT messages and see if that makes any difference.

IQFeed Developer Support » IQFeed freezes Apr 4, 2011 02:06 PM (Total replies: 9)


Thanks for the quick response. I will try and find what happens with the freeze. All I know is that no other application can connect to IQFeed and no GUI interaction is possible with IQFeed and it must be manually killed.

The 15 minute reconnect/disconnect is by the end users design. Basically our application will connect to IQfeed, then 15 minutes later it will exit and restart (and connect to IQfeed again).

I've just gone through our disconnect logic and this is what we do (in C):

1) Unsubscribe to all symbols on the L1 feed.
2) Close the L1 socket
3) Send "S,DISCONNECT\r\n" on the admin socket
4) Close the admin socket

Looking at the code, there is no delay between 3 and 4, I assume therefore that IQfeed might not get the DISCONNECT message. If this is the case, could this cause later issues for IQfeed? Should we be handling the disconnect sequence differently?



Time: Wed September 27, 2023 9:48 AM CFBB v1.2.0 10 ms.
© AderSoftware 2002-2003