Time[] info lost in nested indicators

[DaveE]

Using NT 7 beta 22:

I have an indicator that detects the last bar when an event occurred, then reports the number of seconds ago for that bar.
This relies on accurate information being returned by Time[]
This works fine when my indicator is applied to a basic Price input series (such as High).
But if my indicator uses another indicator (such as SMA(20)) as input series, it seems that NT loses the Time[] info, so everything in the Time[] series contains 1 Jan 1800 !

Does anyone know if this bug has been fixed in v 23?

Is there any workaround to force Time[] to populate in nested indicators?

Steps to reproduce the problem:
1) Create a simple indicator called SecondsSinceLastBar (no parameters) using this code in OnBarUpdate()

if (CurrentBar<1) return;
double val = Time[0].Subtract(Time[1]).TotalSeconds;
Value.Set(val);

2) Put the SecondsSinceLastBar indicator on a 1 minute chart. It displays value 60 as expected.
Now set the SecondsSinceLastBar indicator to use another indicator, such as SMA(20) as the input series. It displays 0. This is because the Time[] array is zeroed (treated as 1 Jan 1800).

Erratic bar durations for sub-minute charts in beta 22:
I thought this test indicator would be useless, but if I apply the indicator to say a 5 second chart (applying the indicator to the default input series (close)), I would expect to see a line at value 5. But the line fluctuates wildly between 5 and 15, showing that NT beta 22 has used erratic bar durations. Has this been fixed by v 23?

[NinjaTrader_Brett]

Hello,

Checking into this with development.

Thank you for your patience.

[NinjaTrader_Bertrand]

Dave, we could reproduce and will look into your finding - thanks for reporting in - for the bar duration, some bars could be longer - NinjaTrader is event based and not time based, as such the old bar is closed when the new bar open tick comes in.

[DaveE]

Hello Bertrand,

Thanks for clarifying the bar duration issue. I understand that is not a bug, but due to inconsistent tick supply from the data supplier (in my case IB). Looking at the tick info I see that IB are sometimes waiting say 6 seconds between ticks. So if this is populating a 5 second NT chart the related bar will have a 10 second duration, instead of the normal 5 second duration.
But the fact that we cant rely on fixed bar durations for sub-minute charts makes access to reliable Time[] info even more important. Here's the reason:

If sub-minute bars always had the same duration we could just count the number of bars to calculate the number of seconds between two data points.
But since these bars dont have same duration (unless you are using a data supplier who consistently supplies a tick per second) we need to rely on Time[] to get the accurate number of seconds between two data points.

But since Time[] is not currently populated for nested indicators: General purpose indicators that rely on time between two data points, could attempt to work round the bug like this:

Is Time[] populated? If so use that for accurate seconds. If not (nested indicator) then estimate seconds by counting the bars and multiplying by the 'standard' bar duration obtained from BarsPeriod info, and just hope there are not too many real bars with much longer duration than the standard.

But this sort of workaround providing information of variable reliability is not what paying users want to deal with, and of course it will not work with charts with no standard bar duration time (such as Range).

[NinjaTrader_Bertrand]

Hi Dave, thanks for explaining your train of thought, much appreciated - we'll review the issues on populating Time[x] in nested indicators and get back to you.

[NinjaTrader_Bertrand]

Dave, we looked into matters and unfortunately the outcome is expected by current design - the input series of your indicator is another indicator series and not the underlying bars series in this case.