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)




"It’s so nice to be working with real professionals!" - Comment from Len
"Just a quick one to say I'm very impressed so far :) The documentation for developers is excellent and I've quickly managed to get an app written to do historical downloads. The system is very robust and pretty quick considering the extent of data that's available. The support guys have been very helpful too, in combination with the forums it's been plain sailing so far!" - Comment from Adam
"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
"IQ feed works very well, does not have all of the normal interruptions I have grown used to on *******" - Comment from Mark
"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
"With HUGE volume on AAPL and RIMM for 2 days, everyone in a trading room was whining about freezes, crashes and lag with *******, RealTick, TS and Cyber. InvestorRT with IQFeed was rock solid. I mean SOLID!" - Comment from Public IRC Chat
"I've been using Neoticker RT with IQFeed for two months, and I'm very happy with both of the products (I've had IQFeed for two years with very few complaints). The service from both companies is exceptional." - Comment from Public Forum
"DTN has never given me problems. It is incredibly stable. In fact I've occasionally lost the data feed from Interactive Brokers, but still been able to trade because I'm getting good data from DTN." - Comment from Leighton
"I "bracket trade" all major news releases and I have not found one lag or glitch with DTN.IQ feed. I am very comfortable with their feed under all typical news conditions (Fed releases, employment numbers, etc)." - Comment from Public Forum
"I just wanted to let u know that your data feed/service is by far the best!!! Your unfiltered tick data is excellent for reading order flow and none of your competitors delivers this quality of data!" - Comment from Peter via Email
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
»Forums Index »IQFeed Developer »IQFeed Developer Support »Time Stamp Data Type Formatting
Author Topic: Time Stamp Data Type Formatting (4 messages, Page 1 of 1)

Seventy77seven
-Interested User-
Posts: 2
Joined: Apr 29, 2020

Named must your fear be before banish it you can.


Posted: Apr 29, 2020 11:11 AM          Msg. 1 of 4
Hi,

I am attempting to configure my API code to pull Futures Market data daily and process. I am using python to connect and insert data into a Postgres table. The problem I am having is that when the data (minute bars) is pulled using this code, the timestamp is formatted as a large number (maybe integer) that appears to be a count of microseconds. This is strange because when I hand pulled the same data from IQfeed and downloaded a csv file the timestamp was formatted correctly with yy/mm/dd/hh/min/sec. Do you have any clues for me to get this format passed correctly in to a Postgres table? Coding is not my greatest strength so any help would be appreciated.

Thanks Mike

Mike

DTN_Gary_Stephen
-Interested User-
Posts: 73
Joined: Jul 3, 2019


Posted: Apr 30, 2020 02:10 PM          Msg. 2 of 4
Mike,

Exactly what command are you sending to the API? No "minute bars" command should be giving you milliseconds, whether it's a history command like HIT, or a BW derivative data command. A tick request could, though, depending upon protocol. Are you specifying a protocol? If so, which one? Let me know the answers to these two questions., and I can give a more specific answer.

Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist

Seventy77seven
-Interested User-
Posts: 2
Joined: Apr 29, 2020

Named must your fear be before banish it you can.


Posted: May 5, 2020 10:50 AM          Msg. 3 of 4
Thanks for the reply. Reading the API documentation says that there are three requests, namely "t" for tick "s" for second and maybe "D?" This led me to believe that the appropriate minute bar request is a 60 second request. This is the code....

get_historical_bar_data(symbol=val[0],
bar_len=60,
bar_unit='s',
num_bars=100)

I am not sure how to answer your "protocol," question. I am working with python and postgres to pull and process the data.

Mike

DTN_Gary_Stephen
-Interested User-
Posts: 73
Joined: Jul 3, 2019


Posted: May 5, 2020 02:40 PM          Msg. 4 of 4
Mike,

First of all, let's talk about the protocol, because that's important to understand. When connecting to the API, you send an S,SET PROTOCOL command to indicate which version of the syntax you want to use. It's a backwards compatibility feature; whenever DTN upgrades the API, it does so in a new protocol number, so existing code may continue to specify the old protocol until they have fully upgraded to it. The most recent protocol is 6.1, so this is the version you should be requesting, by sending S,SET PROTOCOL 6.1 when you initially connect. See http://www.iqfeed.net/dev/api/docs/IQFeedProtocols.cfm for more details.

There are three interval history commands:

HIX - requests a number of intervals
HID - requests all intervals over a range of days
HIT - requests all intervals over a specified date-time range

Based on the presence of num_bars=100, I suspect it is an HIX request. What actually gets sent to the API is:

HIX,[Symbol],60,100

Which return data in the following format:

2020-05-05 15:11:00,300.9800,300.8000,300.8200,300.9100,27132732,35293,0,
2020-05-05 15:10:00,300.9200,300.7600,300.9050,300.8100,27089316,41483,0,
2020-05-05 15:09:00,300.9600,300.8800,300.9122,300.9047,27038363,37991,0,

Getting back to your original question: the date/time already appears to be in the date format Postgres takes. I'm not familiar with Postgres but you may need to convert it to timestamp form to store it:

https://www.postgresqltutorial.com/postgresql-to_timestamp/

Quote: SELECT TO_TIMESTAMP('2017-03-31 9:30:20','YYYY-MM-DD HH:MI:SS');


Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist
 

 

Time: Sat May 30, 2020 1:21 PM CFBB v1.2.0 32 ms.
© AderSoftware 2002-2003