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)

"If you are serious about your trading I would not rely on IB data for serious daytrading. Took me a while to justify the cost of IQ Feed and in the end, it's just a 2 point stop on ES. Better safe than sorry" - Comment from Public Forum
"I've been using IQFeed 4 in a multi-threaded situation for the last week or two on 2600 symbols or so with 100 simultaneous daily charts, and I have had 100% responsiveness." - Comment from Scott
"This beats the pants off CQG, I am definitely switching to the ProphetX 3.0!" - Comment from Stephen
"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
"I've never had DTN go out on me since switching. ******* would go down a couple times every month when I was using them." - Comment from Bryce in AL.
"Very impressed with the quality of your feed - ******* is a real donkey in comparison." - Comment from A.C. via Email
"Version has been working well for me and I appreciate that it is now a much tighter client to work with. I feel I can go to press with my own application and rely on a stable platform" - Comment from David in IA.
"Thanks for the great product and support. During this week of high volume trading, my QuoteTracker + IQ Feed setup never missed a beat. Also, thanks for your swiftness in responding to data issues. I was on ******* for a few years before I made the switch over early this year, and wish I had done it a long time ago." - Comment from Ken
"After all the anxiety I had with my previous data provider it is a relief not to have to worry about data speed and integrity." - Comment from Eamonn
"Excellent datafeed !!!" - Comment from Arely
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: lgwaustralia
About Contact
Joined: Apr 11, 2016 05:38 PM
Last Post: Jun 25, 2019 10:20 PM
Last Visit: Jun 25, 2019 10:20 PM
Website: NA
Location: Australia
Occupation: Programmer
Interests: Trading / Software
Trade on
ICQ: lancelgw
Yahoo IM:
Post Statistics
lgwaustralia has contributed to 16 posts out of 19808 total posts (0.08%) in 1,633 days (0.01 posts per day).

20 Most recent posts:

Just had to change Trading hours to the Extended one and can now see the additional market data in NT.


I see. Thanks!


Thanks for the reply.


Thanks for the reply.

So we'll get them immediately after sending a wSYMBOL. Both Open and Close times will be available then or will a separate fundamental message be sent with the Close Time when the the session ends for the day?

Thanks again.


Is there any way to exclude those additional historical tick data? Was it because of the command string that we sent?

Would like for you to test on your end and see if we get the same result.


Not sure if this is the right place to post but we saw this for the in-development iqfeed 6.1 that the Expanded fundamental data offering includes:

* Open Time - Standard opening time per root.
* Close Time - Standard closing time per root.

and we're wondering if they will be available in both historical and realtime tick data?



After checking with a ninjatrader chart, timestamp that goes back to 20:00 is actually an additional 5 hours of tick data prefixed to the start of the expected historical tick data. Not sure what they are.

Edited by lgwaustralia on Jun 19, 2019 at 10:19 PM

Hi. We are fetching historical data for FDAX. Latest test fetching using HTT,XG#,20190606 000000,20190611 170500,,,,0,,.

The fetched ticks timestamp seems to have been moved back 5 hours from the usual 1am/2am that it usually starts.

So end part of raw data looks ok, ends around 15XX/16XX (we fetch it with closest datetime being retrieved first)

2019-06-11 16:03:24.215000,12154.00,73,105233,12154.00,12154.00,2743249,C,68,01, <== end
2019-06-11 15:59:59.674000,12145.50,2,105160,12145.00,12145.50,2743053,C,68,01,
2019-06-11 15:59:56.711000,12145.00,2,105158,12144.00,12145.00,2743036,C,68,01,
2019-06-11 15:59:55.466000,12144.00,1,105156,12144.00,12145.00,2743032,C,68,01,

Then we get to here where it should had stopped at 1am/2am but goes back passed 0a and back further to previous day

2019-06-11 00:03:16.804000,12114.50,1,1036,12112.00,12114.50,1043420,C,68,01,
2019-06-11 00:01:27.540000,12115.00,1,1035,12112.50,12115.00,1043277,C,68,01,
2019-06-11 00:01:24.790000,12112.50,1,1034,12112.50,12115.00,1043249,C,68,01,
2019-06-11 00:01:07.922000,12112.50,1,1033,12112.50,12115.00,1043221,C,68,01,
2019-06-11 00:00:08.134000,12114.50,1,1032,12112.50,12114.50,1043178,C,68,01, <== new day
2019-06-10 23:59:58.424000,12114.50,1,1031,12112.50,12114.50,1043175,C,68,01,
2019-06-10 23:58:29.982000,12114.00,2,1030,12112.00,12114.00,1043094,C,68,01,
2019-06-10 23:57:50.899000,12113.50,1,1028,12111.50,12113.50,1043073,C,68,01,

This continues until here

2019-06-10 20:15:27.993000,12079.50,1,42,12077.50,12079.50,988692,C,68,01,
2019-06-10 20:15:27.134000,12079.00,1,41,12076.50,12079.00,988677,C,68,01,
2019-06-10 20:15:24.822000,12074.50,1,40,12074.50,12079.00,988646,C,68,01,
2019-06-10 20:15:23.338000,12073.00,39,39,12073.00,12073.00,988556,C,68,01, <== new session start??
2019-06-10 16:03:35.737000,12096.50,37,48420,12096.50,12096.50,988017,C,68,01, <== previous day session end
2019-06-10 15:59:57.689000,12087.00,1,48383,12087.00,12090.50,987387,C,68,01,
2019-06-10 15:59:57.688000,12087.00,1,48382,12087.00,12090.50,987384,C,68,01,
2019-06-10 15:59:55.916000,12087.00,1,48381,12087.00,12091.00,987268,C,68,01,

Same thing happens on the other days:

2019-06-10 00:01:37.788000,12107.00,1,955,12104.50,12107.00,71532,C,68,01,
2019-06-10 00:01:05.796000,12105.50,1,954,12104.50,12105.50,71497,C,68,01,
2019-06-10 00:00:46.297000,12104.50,1,953,12104.50,12106.50,71471,C,68,01,
2019-06-10 00:00:39.994000,12104.50,1,952,12104.50,12106.50,71466,C,68,01, <== new day
2019-06-09 23:59:27.013000,12104.50,1,951,12104.50,12106.50,71426,C,68,01,
2019-06-09 23:59:12.510000,12104.50,1,950,12104.50,12106.50,71423,C,68,01,
2019-06-09 23:58:56.789000,12104.50,1,949,12104.50,12106.50,71421,C,68,01,
2019-06-09 20:15:24.558000,12101.00,1,49,12100.50,12101.00,687,C,68,01,
2019-06-09 20:15:24.556000,12100.50,1,48,12100.50,12101.00,683,C,68,01,
2019-06-09 20:15:24.556000,12101.00,2,47,12100.50,12101.00,681,C,68,01,
2019-06-09 20:15:24.556000,12100.50,45,45,12100.50,12100.50,649,C,68,01, <== ??
2019-06-07 16:03:39.563000,12055.00,37,105100,12055.00,12055.00,12426297,C,68,01, <== session end
2019-06-07 15:59:59.411000,12050.00,1,105063,12048.00,12050.00,12425814,C,68,01,
2019-06-07 15:59:59.401000,12050.00,6,105062,12048.00,12050.00,12425812,C,68,01,
2019-06-07 15:59:59.390000,12050.00,6,105056,12048.00,12050.00,12425806,C,68,01,

Issue appears to have started from 12/10/2018 based on a table we use to keep start / end timestamps for each day's session.

2018-12-04 02:00:00.000000
2018-12-05 02:00:00.000000
2018-12-06 02:00:00.000000
2018-12-07 02:00:00.000000
2018-12-09 19:30:00.000000
2018-12-10 00:00:00.000000 <==
2018-12-11 00:00:00.000000
2018-12-12 00:00:00.000000
2018-12-13 00:00:00.000000
2018-12-14 00:00:00.000000
(part where its DST)
2019-03-07 00:00:00.000000
2019-03-08 00:00:00.000000
2019-03-10 19:30:00.000000
2019-03-10 23:00:00.000000
2019-03-11 23:00:00.000000
2019-03-12 23:00:00.000000
2019-03-13 23:00:00.000000
2019-03-14 23:00:00.000000
2019-03-17 19:30:00.000000
2019-03-17 23:00:00.000000
2019-03-18 23:00:00.000000

Any idea why this happened? a way to fix it?


IQFeed Developer Support » Realtime vs Historical tick resolution Apr 5, 2018 08:07 AM (Total replies: 4)

Thanks for the quick reply. Will try out tSymbol.


IQFeed Developer Support » Realtime vs Historical tick resolution Apr 5, 2018 07:57 AM (Total replies: 4)


Thanks for the reply. I see now that we can match realtime with historical by not processing realtime data that has Message Content that's not C.

Is there a way in realtime to just get Message Contents that are C so we don't have to filter on our end?



IQFeed Developer Support » Realtime vs Historical tick resolution Apr 5, 2018 06:34 AM (Total replies: 4)

Hi there,

We have a system where we use Realtime tick data from IQFeed and then we download all the data for the day at the end of the day as Historical data from IQFeed.

We are seeing that they do not match. For example:

Here is data from a time period we got in realtime: (using command: wXG#)

Here is the data from the same time period we got as historical data: (using command: HTT,XG#,20180404 000000,20180409 170500,,,,0,,)
2018-04-04 07:57:20.072000,11838.50,1,57349,11838.50,11839.50,3106867,C,68,01,

It seems that the historical data is consolidated some how.
Is it possible to get the same resolution as realtime when downloading historical data?



IQFeed Developer Support » Asking about historical data timestamps. Mar 6, 2018 03:21 AM (Total replies: 7)


Thanks for the response. How come IQFeed is not fixing these issues before we get the data.

Are you saying that Ninjatrader is adjusting the data in real-time as it comes in from your servers?

How do they know to do this?

Is there a flag in the data that says the following tick timestamps will all be out by X amount and you need to adjust it?

What other instruments does this happen with?

I was expecting that the data we got from IQFeed was high quality data, and did not contain issues like this that needed to be fixed by end users.


Edited by lgwaustralia on Mar 6, 2018 at 04:17 AM

IQFeed Developer Support » Asking about historical data timestamps. Mar 5, 2018 04:05 AM (Total replies: 7)

Hi again.

I checked the dates in question above ninjatrader using iqfeed as source and loaded up the date range in question. FYI, the times are shown in localtime (PHT) in ninjatrader.

I found that the start times shown in ninjatrader seem to follow the daylight savings time. It changes start of open from 15:00 / 3pm PHT on March 24, 2017 (Friday) to a 14:00 / 2pm PHT on March 27, 2017 (Monday).

It then goes back to starting at 15:00 / 3pm PHT on October 30, 2017.

So how do we deal with this? Should we:
- update the historical data we have in database to follow DST conventions (changes to 3am EST on march then goes back to 2am EST past last sunday of october)
- OR change them so they will all start 2am EST.



IQFeed Developer Support » Asking about historical data timestamps. Feb 27, 2018 08:04 AM (Total replies: 7)

Okay I see now. US goes, with dsts, 2nd sunday of march while they do last sunday of march and in between those dates it will appear as 3am. The same happens with the dates during transition back, last sunday of october for europe and first sunday of november in US.



IQFeed Developer Support » Asking about historical data timestamps. Feb 27, 2018 07:30 AM (Total replies: 7)

Thanks for replying.

We are using symbol XG# with method HTT.

> but since markets don't trade Sunday morning, DST doesn't make us much difference.
Ah since dst change happens on a sunday, then monday comes and should still open at 2am ET is that correct?

Thanks again.


IQFeed Developer Support » Asking about historical data timestamps. Feb 27, 2018 03:13 AM (Total replies: 7)

I wanted to ask about the timestamps of some historical data. Also would like to ask about the timezone if it's still EST and if timestamps observer daylight savings time.

So i have this set of timestamps and trade opens at 2am EST, changes to 3am around november so that's the daylight savings, then goes back to 2am on nov 11. I thought it would have stayed at 3am until march when it reverts back to 2am: (Edit: pm to am)

(shows only specific dates where transition occurs)
(transtion from 2p to 3p on nov2016)
"2016-09-01 02:00:04.381"
"2016-09-15 02:00:03.884"
"2016-09-20 02:00:06.72"
"2016-10-20 02:00:05.545"
"2016-10-25 02:00:37.324"
"2016-10-31 03:00:05.133"
"2016-11-01 03:00:04.63"
"2016-11-02 03:00:05.146"
"2016-11-03 03:00:03.583"
"2016-11-04 03:00:03.148"
"2016-11-07 02:00:03.947"
"2016-11-10 02:00:06.397"
"2016-11-15 02:00:06.662"
"2016-11-24 02:00:03.19"
"2016-11-25 02:00:06.682"
"2016-11-28 02:00:03.653"
"2016-11-29 02:00:05.423"
"2016-11-30 02:00:05.156"

(transition from 2p to 3p in mar2017)
"2017-03-01 02:00:04.376"
"2017-03-10 02:00:06.082"
"2017-03-15 03:00:04.078"
"2017-03-20 03:00:04.517"
"2017-03-27 02:00:07.559"
"2017-03-28 02:00:04.393"
"2017-03-29 02:00:03.89"
"2017-03-30 02:00:05.692"

(transition from 2p to 3p in nov2017)
"2017-10-05 02:00:10.811"
"2017-10-10 02:00:07.772"
"2017-10-20 02:00:05.902"
"2017-10-25 02:00:07.685"
"2017-10-26 02:00:05.272"
"2017-10-27 02:00:04.593"
"2017-10-30 03:00:07.905"
"2017-11-01 03:00:08.247"
"2017-11-10 02:00:05.471"
"2017-11-15 02:00:04.3"
"2017-11-20 02:00:09.104"
"2017-11-27 02:00:10.51"
"2017-11-28 02:00:16.352"
"2017-11-29 02:00:13.293"

Edited by lgwaustralia on Feb 27, 2018 at 07:34 AM

Time: Tue September 29, 2020 9:21 AM CFBB v1.2.0 16 ms.
© AderSoftware 2002-2003