||Mar 26, 2008 09:40 AM
||Sep 17, 2020 05:03 PM
||Sep 17, 2020 05:03 PM
Roberts has contributed to 23 posts out of 19808 total posts
(0.12%) in 4,570 days (0.01 posts per day).
20 Most recent posts:
And TREX charts at TDAmeritrade are still not adjusted. Another conspiracy theory out the window!
2 days after ex-date. TREX daily history is still not adjusted. I'm looking at it in TDAmeritrade and it's not adjusted there either. Really strange this one!
TREX when ex-split today. The partial daily bar from today, reflects the split (of course). However, the history bars prior to the ex-date are not split yet. Why is that? When does that happen and does it depend on the exchange?
Looks good now. SF2 is empty. Thanks.
I just grabbed the message after reading your post and got this:
F,XLF,7,,57698000,31.3800,17.4900,31.3800,17.4900,2.4700,0.1516,0.6115,06/25/2020,06/22/2020,,,,,FINANCIAL SELECT SECTOR SPDR,,,1.20,,186563.0,,,,744245,0.81 09/19/2016,1231.00 02/22/2008,...
Indeed, Split Factor 1 was corrected, but Split Factor 2 should be empty. The factor 1231 is an artifact of the divisor for Split Factor 1 (1000/1231 = approx. 0.81), and its date is fictitious.
Is this a good place to report data errors?
The fundamental message returned just now for XLF begins like this, with the record truncated after Split Factor 2
F,XLF,7,,57698000,31.3800,17.4900,31.3800,17.4900,2.4700,0.1516,0.6115,06/25/2020,06/22/2020,,,,,FINANCIAL SELECT SECTOR SPDR,,,1.20,,186563.0,,,,744245,1000.00 09/19/2016,1231.00 05/04/2007,...
An hour earlier, this came in...
F,XLF,7,,57698000,31.3800,17.4900,31.3800,17.4900,2.4700,0.1516,0.6115,06/25/2020,06/22/2020,,,,,FINANCIAL SELECT SECTOR SPDR,,,1.20,,186563.0,,,,744245,1000.00 09/19/2016,1231.00 07/01/2002,....
I only noticed this because a customer reported that the date he got for Split Factor 2 was 10/12/2010.
Besides the changing date for this "split", a bigger problem is that there has never been a second split for XLF. There should only be the first on 9/19/2016, whose factor should be 1000/1231 (approximately). In reality, the factor should be 1/1.23167675 which is really a back-adjusment for a special dividend of $4.44346/share.
Thanks Gary. It's good to know. Despite that inconsistency, I've figured out a way to keep it all straight anyway by recording the first time a new split appears in the message and comparing it to the last data file write time. Knowing the Date/Time of end of the session before the ex-date, we can process a split for intraday data when appropriate.
Can you explain the Fundamental message for TREX then? Split Factor 1 is "0.50 09/15/2020".
Checking other sources, this one is curious because the "Record Date" is 8/19/2020, but the Ex-Date is 9/15/2020. Most often record dates are on or even 1 day after the ex-date. Does the record date influence when the split appears in the Fundamental Message?
Apologies for the hassle, but I'm trying to determine a method to split intraday history using Split Factor 1 (and other meta data).
Thanks teresa. Let me run something else by you...
On Monday 31 Aug, TSLA and AAPL will both start trading ex-split. Here's the problem - I just checked today (Saturday morning 29 Aug) that the splits don't appear in the Fundamental Message.
Our customers generate trading alerts based on the closed session's data. Imagine an alert to by 25 shares of AAPL at a $490 limit. This order will be transmitted to the broker (and if the broker doesn't automatically cancel it) this order will execute at market. We need to adjust the data before the ex-date. Consequently, adjusting for the 4:1 split, the strategy would correctly generate an order to buy 100 shares at $122.50.
The best solution would be post that adjustment before the ex-date - it could even be days before. Just like DTN does for pending dividends, post a pending split in the Fundamental Message so clients can adjust as required and when required. This would be a GREAT help!
Thanks Stephen. Really appreciated.
I just discovered that the Split Factor 1 and 2 items in the Fundamental Message are limited to 2 decimal precision! That's too imprecise for common 1.5:1 or 3:1 splits (and also 6:1, 7:1, etc). I use these values to adjust the intraday data and the Daily cache when a new split arrives.
Take the 7:1 AAPL split on 6/9/2014. The factor given is 0.14 instead of 0.142857143. However, the IQFeed daily data appears to be adjusted using more precision - even though the data are only precise to 4-decimals.
Can IQFeed increase the decimal precision of the split factor to at least 8 decimals? 6?
Heads up for AAPL and TSLA on 8/31 ;)
fwiw, I second the motion for a variable LAN IP. Many of the customers we're sending to IQFeed now run Wealth-Lab on two machines simultaneously.
This morning is 8/19/2020 and I'm requesting data for 3 stocks whose split ex-date was *yesterday* 8/18/2020. QLD (2:1), SSO (2:1), and SQQQ (1:5). The first two are still not returning split data and their splits are not identified in the Fundamental message. SQQQ, however, is okay. When can we generally expect splits to be processed?
SSO Split Factor 1: 0.50 05/20/2015
SSO Split Factor 2:
QLD Split Factor 1: 0.50 07/17/2017
QLD Split Factor 2: 0.50 05/20/2015
SQQQ Split Factor 1: 5.00 08/18/2020
SQQQ Split Factor 2: 4.00 05/24/2019
I'm going to quit! I had set the protocol to 6.1 only for the history socket. The level 1 socket defaults to 4.9, so there's the difference. The field order above is 4.9. The doc is updated to 6.1.
While I don't know what the table isn't update, the order of the fields from the S,REQUEST FUNDAMENTAL FIELDNAMES request appears as follows and reconciles with the fundamental data received.
0 FUNDAMENTAL FIELDNAMES
2 Exchange ID
4 Average Volume
5 52 Week High
6 52 Week Low
7 Calendar Year High
8 Calendar Year Low
9 Dividend Yield
10 Dividend Amount
11 Dividend Rate
12 Pay Date
13 Ex-dividend Date
17 Short Interest
19 Current Year EPS
20 Next Year EPS
21 Five-year Growth Percentage
22 Fiscal Year End
24 Company Name
25 Root Option Symbol
26 Percent Held By Institutions
29 Current Assets
30 Current Liabilities
31 Balance Sheet Date
32 Long-term Debt
33 Common Shares Outstanding
35 Split Factor 1
36 Split Factor 2
38 Market Center
39 Format Code
42 Historical Volatility
43 Security Type
44 Listed Market
45 52 Week High Date
46 52 Week Low Date
47 Calendar Year High Date
48 Calendar Year Low Date
49 Year End Close
50 Maturity Date
51 Coupon Rate
52 Expiration Date
53 Strike Price
55 Exchange Root
56 Option Premium Multiplier
57 Option Multiple Deliverable
I can reconcile many of the fields to indexes where the data are appearing (like Company Name), but there was a mistake in the previously-attached file due to a few merged cells from the spreadsheet, but this doesn't affect the discussion. If you look, import this attached one into Excel.
Please help me with the field order for ..dev/api/docs/Level1FundamentalMessage.cfm
Here's the fundamental message for TSLA received today:
"F,TSLA,5,775.0,13022000,1794.9900,211.0000,1794.9900,350.5100,0.0000,,,,,,,,,,2.13,,,12,,TESLA INC.,,38.,1.42,,12103.0,10667.0,06/30/2020,11634.0,186362,336211, , ,,0,14,4,3711,80.92,1,21,07/13/2020,08/23/2019,07/13/2020,03/18/2020,418.33,,,,,336211,,"
Assuming F is field number 0, the data correspond well to the Level1FundamentalMessage field order up to index 9. However, the next value available is at index 19, which is "2.13. The table, however, indicates "Root Option symbol (there may be more than one)" for index 19.
The Company Name, TESLA INC. appears at index 24, but the table suggests that Company Name should be at index 18.
I've attached a tab-delimited txt document that aligns the data in this message with the descriptions for Level1FundamentalMessage.cfm. What's going on here?
I'm looking at fundamental fields for the first time (and trying to find a forum thread that discusses the field order because it dertainly doesn't correlate to the table given at /api/docs/Level1FundamentalMessage.cfm)
Anyway, for TSLA field 4 (starting from 0), which is supposed to be the "Average daily volume in 1000's of shares (4 week average)", returned 13022000. This is the currect value for shares traded (in 1's, not in 1000's).
Thanks for the info Gary. I was aware of the Level 1 approach and we'll do that for streaming charts. That doesn't help for the history, which our customers use for backtests. Instead of bulky tick history requests to just find an opening price, we'll just post-process and massage that data with the daily bar's opening price. I'm hoping that'll work!