Random past time hit OnBarUpdate() causing Strategy to calculate trend incorrectly

[timwelch]

Hi there!

Long time NinjaTrader user, paid lifetime subscription, etc etc.

I've been programming indicators/strategies for a few years now on NinjaTrader (moved from Metatrader).

I have a Strategy that I was watching this morning, and it decided to change the trend direction based on a call to OnBarUpdate() that had a timestamp of 4 hours in the past. Any indication as to why this would happen? I can codify that unwanted behavior out of my Strategy easily, with my own Time variable that would save the last Time[0] and return out of the top of OnBarUpdate() if any new Time[0] is in the past.

But I am really curious as to why this happened in the first place. Is it an issue with NinjaTrader? It clearly is not an issue with my Strategy, as I don't call OnBarUpdate() and I don't muck with the Time[0] series in any way/shape/form.

Here's a screenshot for evidence.


Thank you for your assistance!
Timothy Welch

[timwelch]

Just for further evidence, The code snippets for those print statements use Time[0] directly.


Print(Time[0] + " - [ " + Name + " ] - " + "Changing direction to downTrend. waitForBreakLow: " + waitForBreakLow + " prevSwingLow: " + prevSwingLow + " prevSwingHigh: " + prevSwingHigh + " lastLow: " + lastLow + " lastHigh: " + lastHigh);

[NinjaTrader_Jim]

Hello Timothy,

Thanks for your post.

Time[0] will reflect the timestamp of the developing bar or the bar that had just closed depending on the Calculate mode that is used with the script. These timestamps are most often stamped by your data provider and NinjaTrader uses them as is. You can check our Data By Provider grid to see which of our supported providers offer native timestamps.

Data By Provider - https://ninjatrader.com/support/help...y_provider.htm

It is technically possible to have a tick based bar whose last tick came 4 hours before the next tick that opens the new bar. Time[0] would then represent the timestamp of the last tick that builds the bar, and the next tick that opens the new bar will signal the bar closure. OnBarUpdate then would be called to process that bar that has just closed.

If you are observing any other discrepancies, I would suggest making sure that the PC clock is in sync with internet time.

Please let us know if there is anything else we can do to help.

[timwelch]

Thank you for your response, Jim.

I use NinjaTrader Continuum as my data provider, and my computer is set correctly to the proper time and using NTP to keep its time correct.

I am running on an 89 Tick chart, viewing the YM (Futures Dow). As the screenshot shows, this occurred at 9am, just before the stock market opened.

Are you telling me then that NinjaTrader Continuum data feed is to blame, and that I could actually get a tick from 4 hours ago? That seems very much out of line with what I've been led to believe by the data providers and their consistency of feeding said data.

[NinjaTrader_Jim]

Hello Timothy,

NinjaTrader signals bar closes and processes OnBarUpdate after we see the first tick of a new bar. It is possible to see one tick come in which would be the last tick to build that bar, and then 4 hours later the next tick to open the next bar and triggers OnBarUpdate. Time[0] would reflect the timestamp used to build the bar. This would not be consistent with the newer timestamps seen before the 5:47 prints, however.

Could you confirm that the script is not adding an additional data series?

Do you see this issue after reloading historical data on the chart? (Right click > Reload All Historical Data.)

Is this something that can be reproduced and can you confirm that this can be reproduced without any other scripts running?

I look forward to being of further assistance.

[timwelch]

I can confirm that the script is not adding any additional data series.

I have not seen the issue happen again, and I have no clue how to reproduce as I'm not in control of the data feed coming into Ninjatrader.

However, I did add code into my strategy to detect such an event and log it into the output window. So if it does happen again, I will see it.

Here's the code snippet that I added to OnBarUpdate(), DateTimeToUnixTimestamp is a function I wrote to do just what it says. That just converts the string time into an epoch timestamp, to make it an easy comparison:



// 2019-02-12 - Check to ensure no bars in the past are showing up.
double tTime = DateTimeToUnixTimestamp(Time[0]);
if (lastTime > tTime) {
Print(Time[0] + " - [ " + Name + " ] - " + "OnBarUpdate(): Bad Time[0] received. Time[0] is in the past: " + Time[0] + " tTime: " + tTime + " lastTime: " + lastTime);
return;
}
lastTime = tTime;

[NinjaTrader_Jim]

Hello Timothy,

Thanks for replying with that information.

If the ticks with those timestamps is saved to your local data repository, we should be able to see the same print by applying the NinjaScript against the same data series. For tick based bars, we can set the End Date for the data series and use Days To Load to get the the Bars object for the data series to start at the beginning of a session and build the same bars consistently. (If we use Bars To Load, we will always have a different starting tick to build the tick based bars.)

If you can encounter the same timestamps taking this approach, I would then suggest performing the Reload All Historical Data operation in case there was an issue with the data that was previously requested and made its way to the Output window prior.

For your print, I may also suggest adding the script's State, so if the issue comes up again, we can quickly see if it has occured with historical or realtime data.

I look forward to being of further help with this matter.