DataSeries End Data

[rt-trader]

Hi,

When setting a date less than the current date for a chart to load, the enetered end date is ignored and data is loaded from the current date.

Using b10

[NinjaTrader_JoshP]

I could not reproduce. Told the chart to end on 2/26. Chart comes up as 2/26 chart. From your other reports too it sounds like your NT7 has many odd behaviors. I suggest you try a 100% clean reinstall.

[rt-trader]

Josh,

My NT7 doesnt really have 'many odd' behavious - just two...

Anyway, I did a clean install as you suggtested - and the issue still exists - but I think I can see what is happening.

Question - does NT cross check an end date against the session template selected for the Data Series load?

Perhaps it is taking the end date as the chart start date for the last day and assumming that it is also the end date?

For local timezone day session only instruments that would work, for those in different timezones or where session templates run across midnight the chart end date can be 1 day later than the start date.... and a day later than the selected end date in the dataseries load (if the session template is not properly taken into account)

Maybe .....

[NinjaTrader_JoshP]

rt-trader,

Time zones do make a difference. Your end date is only reflective as the starting date for the last session. If the session goes into the next day, your chart will follow accordingly.

[jdfagan]

I reported this same issue in different thread. If NT treated our end date as the date at END of session of last trade day then all would be good. But instead it treats our end date at START of session of last trade day which is usually what we don't want when using local timezones.

Seems like easy fix - hopefully they will start to see this as issue from end user/trader point of view.

[NinjaTrader_JoshP]

jdfagan,

It is not that simple. For example, someone living in a time zone offset from EST so most of the session is in the correct date. A few hours are past midnight into the next day. This user may expect the exact opposite behavior as you. They would punch in the end date and expect it to load the full session as it crosses into the next date.

Furthermore, even going down your thought path for your scenario. Let us say we want to chop off the chart at 3/2. The last session for 3/2 would really be the Monday session as you crossed over midnight. So you end the chart at the end of the Monday session. Chart shows as 3/2, user doesn't get any updates for 3/2 and complains, "Why aren't my charts updating? Today is 3/2. The chart isn't updating". This would be even more unexpected.

It is basically a pick your poison situation. We went with this route because most people think in relativity to the date. For example, "I want to chart the Monday session". Monday was 3/1. So I will plug in 3/1 even though it crosses into 3/2.

[jdfagan]

Josh,

I understand development's point of view being a software engineer myself. So I'd like to make a design alteration suggestion then which would satisfy both use cases a bit better IMO:

* End Date when SET: means the end of session of last trading date. As new data or even new dates come in after end of session already detected for this date, its not processed for this chart.

* End Date when NOT set (i.e., left blank) or perhaps you have a special date value which means to leave it open ended (i.e., to always follow the right edge as we move thru time): means that right edge of chart will always be live

What I'm trying to point out is the very different use cases that one can use charts - one for accurate, precise backtesting vs. realtime trading charts. Instead of trying to shoe-horn in the setting of end date to satisfy both use cases (which it does one poorly currently IMO), try to allow end date to either mean what it really implies it to mean or let it be set to null/blank/open ended type date. Then you can get best of both worlds. In this design approach, it would be wise to have end date default to null/blank/open so it by default tracks leading right edge as most users would want, but allow for the occasional (or frequent depending on the end user) precise backtesting to be done when warranted.

Regards,

JD

[NinjaTrader_JoshP]

JD,

Thanks for the alternative approach feedback. I have added your request to our feedback list.