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 21240 total posts (0.24%) in 5,375 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: Tue July 16, 2024 7:08 AM CFBB v1.2.0 7 ms.
© AderSoftware 2002-2003