TradingView Backtest Start Date: Why NQ Results Change

Changing a TradingView backtest start date can change trades inside a period that appears in both reports. The reason may be earlier indicator calculations, a different initial position, or a switch between chart-based testing and Deep Backtesting. Comparing the final profit totals will not tell you which one changed.

For an NQ or MNQ test, record when calculations begin and when new trades become eligible. Then find the first different decision in the overlapping period. That gives you a practical way to investigate the discrepancy before changing the strategy.

Record two starting points

The calculation start is the first bar processed by the script. In ordinary chart-based testing, available history and script configuration determine that starting point. Pine can also limit execution with its calculation-bar setting. A date written in your research notes cannot create missing price history. See TradingView's execution model.

The trade start is the first time your rules permit a new entry. A custom date filter can allow indicators to calculate on earlier bars while blocking entries until a chosen timestamp. TradingView's date-filter example calculates RSI separately from its entry eligibility conditions.

Suppose you want to evaluate September trades. One setup calculates from August but allows entries only from September. Another starts both calculation and trading in September. Their September prices may match while their starting indicator values differ.

Also distinguish the loaded dataset from the candles currently visible on screen. A zoomed-in view is insufficient evidence of where calculation began. Record the actual available history and the selected testing mode.

A script's date input can have different meanings depending on its implementation. Check its documentation or source. Use only controls actually offered by the strategy; the examples here describe general testing methods and do not establish which date controls AORDS provides.

Give indicators time to initialize

Warm-up is the history processed before the period you intend to evaluate. It lets calculations build the information they need. A lookback-based rule needs earlier observations; a recursive calculation also carries part of its previous value forward.

TradingView identifies EMA calculations and other history-dependent functions as sensitive to a dataset's starting point. Early differences can propagate through later bars. Available history can change with the data provider, account limits and dataset alignment. See its explanation of starting-point changes.

Consider a hypothetical smoother that gives the newest price 10% weight and its previous value 90%. If two initial estimates differ by 10 points, identical subsequent prices reduce that difference to 9 points after one update and 8.1 after two. This arithmetic illustrates how an initial difference fades gradually.

Even a small remaining difference can matter when a rule sits close to a threshold. One run might register a crossing while the other waits. If that changes a position, later trade results can diverge even after the indicators become nearly identical.

There is no universal warm-up length for every strategy. For your test, extend the calculation history while keeping the trade window fixed, then compare the resulting signals. Decide your tolerance for indicator differences in advance and check whether trade decisions stabilize.

For custom Pine code, calculate history-dependent functions consistently before applying entry eligibility checks. Placing those calculations inside a condition that skips earlier bars can prevent the intended preparation. TradingView explains this issue in its guidance on time series in conditional scopes.

Keep Deep Backtesting and chart results separate

Deep Backtesting can use historical data beyond the bars loaded on the chart. Its availability depends on your TradingView plan and the available dataset. TradingView's Deep Backtesting guide describes the current feature.

Crucially, Deep Backtesting uses the selected date range for calculation, subject to available history and platform limits. Selecting a later start can therefore change the calculation history itself. EMA and RMA values can differ from an ordinary chart calculation, including within overlapping dates. See why the two modes can produce different results.

Check the actual range available. TradingView's data limits and additional continuous-futures restrictions can shorten the requested history.

Deep Backtesting trades appear in its report. The trade markers on the main chart continue to come from the ordinary chart calculation. Comparing a deep-history trade list with those markers mixes two runs. TradingView confirms this in its chart-display explanation.

If you need a separate warm-up interval within a deep-history test, that requires an appropriate script-level trade filter or another documented testing method. Merely choosing September as the Deep Backtesting start does not supply August as preparation.

Check the position at the boundary

Imagine a hypothetical strategy that buys near the end of August and holds into September. A longer simulation reaches September already long. A fresh run that prevents all August entries reaches September flat. If the rules permit only one position, the two runs may respond differently to September's first signal.

Write down which question you are studying: starting the strategy flat on the chosen date, or examining that month's activity within an already-running simulation. For the latter, record any carried position and the account state at the boundary. Earlier gains and losses can also affect later quantities when sizing depends on equity.

Check pending orders as well as filled positions. Under TradingView's default strategy behavior, an order created at a bar's close can fill at the next bar's open. The signal timestamp and entry timestamp can fall on opposite sides of your boundary. See orders and trades.

Define the end boundary too. Decide how your analysis treats positions still open at the cutoff and orders awaiting a fill. An entry filter alone does not specify a complete end-of-test liquidation policy.

A reproducible NQ comparison

Use this sequence when two reports disagree:

1. Save the baseline. Record the script version, inputs, exact symbol, timeframe, chart type, session, contract or continuous-series settings, position sizing, costs and execution assumptions. Save the report and its settings together.

2. Write exact boundaries. Record calculation start, allowed entry start, end timestamp and the intended initial position. Include a named timezone. The chart's timezone is a display preference, so changing it alone does not change script time calculations. See TradingView's timezone documentation.

3. Change one variable. For a warm-up investigation, keep the trading window fixed and change only the earlier calculation history where supported. For a trading-start investigation, keep history fixed and move only entry eligibility. Record any setting you cannot hold constant.

4. Compare the same dates. Use matching report modes and inspect the overlapping period. Check whether the first difference is a signal, pending order, filled position, quantity or exit. A larger total from a longer test may simply include more trades.

5. Inspect the preceding state. At the first mismatch, compare accessible indicator values, position size, prior orders and relevant session conditions. If a protected script hides the required values, record the uncertainty and ask its author what determines initialization.

6. Repeat the saved setup. Re-run the unchanged configuration and preserve the export with the run date. Record revised source data or software changes if they appear. Reproducibility requires enough detail for another person to reconstruct the experiment.

Interpret the difference before judging performance

If changing only preparation history alters early trades, initialization is a useful hypothesis to investigate. If the first mismatch begins with a carried position, examine the boundary policy. If indicators agree but fills differ, widen the investigation to execution assumptions using the AORDS backtest-versus-live guide.

Choose your evaluation dates before reviewing which interval looks most profitable. Preserve less favorable runs alongside favorable ones. A repeatable result helps explain the simulation, but cannot establish future profitability.

AORDS performance figures are backtested and exclude commissions and slippage. For your own testing, document cost assumptions and evaluate their effect separately. Explore related testing and risk topics in AORDS Learn.

The useful outcome is a clear explanation of the first divergence, supported by saved settings and trade records. Once you know which starting condition changed, you can make a meaningful comparison.