Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Accuracy of SC Denali data, and a data reconciliation request
I'm thinking I may have spoken too soon in by last post about SC and the CME data. I don't honestly have time to look at this right now, but I think it just may be that there were actual trades on Friday, but the official daily data doesn't include them because of the way CME reports their trade date, which I think is not the same as their calendar date. I believe I've run into this before. I'll edit some of that post, and hope this is the resolution.
If it is, then yes, there will always be an anomaly with partial sessions on holidays, because that is the CME stance on how they report it. I think this has to be lived with.
Bob.
When one door closes, another opens.
-- Cervantes, Don Quixote
I'll be the first to admit that I am not an expert on how exchanges report data and how the plumbing ultimately works with these data feeds, but if I'm paying for data I should have a reasonable expectation of accuracy and completeness. I know I'm repeating myself when I say this, but I do consider it important to have complete and accurate data when conducting historical analysis and strategy backtests.
The fact is that FX and rates markets were open and any open positions or orders on those days would have been live.
And even if the exchange sees fit to omit those data, the other (free) historical data providers include it. I wish that Denali did as well.
SC support, meanwhile, has once again lived up to its well-earned reputation of being rude, dismissive, and unprofessional.
Out of curiosity, are there any traders here using different (non Denali) data that do show April 2 price and volumes in their historical daily feed?
At this point, I think this is a good question, and I'd like to see other responses. I am coming around to the idea that CME is going to report the data the same as SC does (actually, that SC is reporting it the same as CME, right?) and that nothing can be done when dealing with historical daily data with partial sessions due to holidays.
See the post I just made up above, after my first one, which is now somewhat edited.
I do agree about the SC attitude problem. It would have taken them no more time to explain why their mumbers are what they are than it took to blast you.
If there's another answer to the data question, I assume someone will post about it.
Bob.
When one door closes, another opens.
-- Cervantes, Don Quixote
This is all a little puzzling, but I wonder how important it actually is.
There are perhaps a dozen holidays, give or take, in a full year, probably fewer. Unless each individual bar is very important to whatever you are backtesting, having a few that are anomalies probably will not matter in the sense of throwing you off. This may not always be the case, but I think it usually will be.
For example, when I look at daily data I am mainly just interested in trends over multiple days, usually quite a few (weeks and months.) I don't know that one day being off actually matters that much. If it does, I will be looking at intra-day data, which should cover all the trading on that calendar day.
There is also the probable reason that CME treats these partial days this way, at least what I assume (guess) is the reason. Typically these are very low-participation days, very often either US holidays (very few US traders active) or international holidays (very few traders active from anywhere.)
As a rule, trading ends on these semi-holidays in the early afternoon US time, which I have always assumed is mainly to accommodate European traders, who will be out of the markets in the 11:00 or 11:30-ish (Eastern Time) period due to the time difference. Most US traders will stay away entirely, at least for US holidays. An example would be the US July 4 holiday, if it isn't on a weekend. No Americans are going to be trading, and the US stock markets will be closed. So there is usually just a small amount of light non-institutional trading, which would drop off to near-zero as Europe closed down. (I believe that equity contracts closed at 08:15 US CT on Good Friday. Not much point to even recording that data point.)
Other markets will have other characteristics, but in general I think that trading is going to be light on the partial holidays. If there's not much trading, you could ask whether it's actually that important, in terms of identifying what is happening in whatever market it's in.
So the question basically is, how much do a few odd days a year actually matter? It would be good to know the reason for the oddness, but I don't think it will usually make a great difference.
Bob.
When one door closes, another opens.
-- Cervantes, Don Quixote
Bob is absolutly right, these short days (with early close) are not important, special for backtesting.
Most platforms show these days, but maybe there is a setting that excludes these days. Perhaps you should watch for it, I don't know it, because it is years ago, that I have used SC.
Denali Daily data (.dly) did not included Good Friday.
Denali intraday data (.scid) has data for Good Friday.
A 1Day 1-0-0 intraday chart will look similar to Schnook's post from the CME, so its comparison to Denali is from two different data. Even so, I was not able to create a chart that matched CME's. See pic.
Specific dates can be excluded from displaying by editing the Symbol Settings: sierrachart.com/index.php?page=doc/ChartSettings.html#DatesToExclude
(Copy/Paste the above because this forum doesn't allow # in the url.)
I appreciate what you guys are saying, but for my purposes I actually do require this holiday data. To wit, I am doing a lot of seasonal, calendar-based analysis right now that specifically requires these holiday sessions to be included. And to a bond trader, this past Friday - when the employment report was released - is in fact an extremely important data set.
The other part of this whole issue is that as a paying customer of the new Denali data feed I simply wish to conduct some due diligence, and in doing so, I have now noticed a few errors, which frankly makes me question the accuracy of the data in its entirety.
Here's yet another example:
Thursday, April 1 was NOT a holiday, yet the Denali daily historical data shows volume in June RTY of just 9216 contracts, while the intraday data shows total volume of well over 100,000 contracts. So the data actually contradicts itself. This does not inspire confidence. Again, I need my data to be accurate and reliable, and my due diligence thus far shows that not to be the case with Denali.
The reason for the discrepancy between a Daily chart and a 1Day intraday chart is explained in the documentation.
It has to do with when the day starts and ends, and the date stamp of the bar: https://www.sierrachart.com/index.php?page=doc/SessionTimes.php
You'll also find that they will rarely be exactly the same.
You might be chasing a phantom issue.
No this is real. RTY traded way more than just 9216 lots on Thursday. Sierra Chart has also just now acknowledged that it's incorrect and have stated that they will ask their data provider about it.
If you look at the screenshot I attached to my last post you will see the obvious error. And anyone who uses volume as an input in a trading strategy should care about this.
Perhaps they are not important to you, @tr8er, but for me they are critical.
Again, perhaps I'm in the minority here, but I need my data to be both accurate and complete. At least among professionals I know that I am not unique in this regard.
