Making a COM call to RequestDayHistory has a parameter for # of days.
This always returns 3 trading days when 3 are asked for.

However, RequestMINUTEHistory has a parameter for # of days, but the results depend on the day of the week, or holidays.
A weekend and a market holiday (or other special observances) means I might not get any days, or 1 or 2 or 3 days of data.

Can the Minute history be made consistent like Day, Week and Month history requests?

I know you have the data to figure this out :)

I can add code on my side, but you did such good job with Day/Week/Month. Also, its not simple to recongize imprompto market closings for presidents, etc. Whereas you have the trading days known already.

Thank you

There is actually nothing built into our system that recognises "trading days".

The reasoning this is done this way is so that it is universal to all markets and exchanges.

All of our history data is built from the trades that come through the Level 1 Feed.

Our servers have a nightly process that builds daily/weekly/monthly data from the current day's ticks. If there are no ticks, then there is no daily datapoint created. If there is even a single trade, then a daily datapoint gets built.

This same behavior also extends to minute history vs tick history. If no trades happen in an interval, no minute datapoint is returned for that interval.

While it would be possible (although not necessarily "easy" due to the way the system is setup) to account for non-traded days in minute history, it would require a change in protocol that would require most of our 3rd Party Applications to update thier software to accomodate.

As a result, it is not likely that a change such as this will happen soon but it is certainly a possibility for the future at some point.

Hi Steve,

I think he's actually arguing the opposite. Today, a HD query gives you trading days, whereas an HM query gives you calendar days.

If it's a Sunday, and you query one day of daily history, you'll get Friday's data. If you query one day of minute history, you get nothing back at all.

While I agree there'd be a 3rd party application problem, this inconsistency is confusing and sometimes difficult to work around. Somewhere in your server, you must have a comparison to calendar date when an HM query is done, but a simple "days of datapoints" comparison when an HD query is done.

You are correct that there must be a calendar date calculation somewhere in the history server but I would guess (I don't deal with the server code at all) that there is not a "days of data points" comparison done.

The reason, is that with a daily/weekly/monthly/"lastX ticks" request, you are requesting a specific number of data points. Whereas, with a minute/"tick days" request, you are requesting an indeterminate number of data points so the date calulation has to be made. Due to the way the history servers work (as described above), they build trading days automaticly for requests that you specify the number of data points.

We understand that there are flaws with the current system and it should be possible to make this an option in the future. Right now it wouldn't be an easy thing to implement but we will keep it in mind for future development.