MT5 iBarShift: Missing Bars and Earlier-Time Matches

Published: 2026-11-12 | AlgoWay | View Markdown

A timestamp can be perfectly valid while the requested MT5 candle does not exist. A market closure, a gap in the available history or a request outside the loaded range can leave a lookup with no matching bar.

MQL5's iBarShift can return an earlier bar when no matching bar is found. That is useful for some historical comparisons, but a nonnegative result is not proof that the observation is fresh enough for your trading rule.

This matters in automated trading whenever a rule aligns events with price history. When reviewing a TradingView-to-MT5 workflow through AlgoWay, keep the original signal time separate from the time of the MT5 bar used in your own analysis. An earlier-bar substitution in an analysis script should not be mistaken for evidence that the connector delayed an order. The lookup behavior below belongs to the public MQL5 API, not to a claimed AlgoWay setting.

Choose the missing-bar policy explicitly

The official iBarShift reference defines the return value as the index of the bar corresponding to the requested time. Its exact argument controls what happens if that bar is not found:

• With exact=false, the fallback is the nearest bar whose opening time is earlier than the requested time. If no such history exists, the result is -1.
• With exact=true, there is no nearest-bar fallback: a missing match returns -1.

This is not a bidirectional search for whichever candle happens to be closest. Nor does enabling fallback create a candle in a hole in the history. It selects from available bars.

Walk through a missing five-minute interval

Imagine a deliberately simplified M5 history with bar opens at 09:55, 10:00 and 10:15. Assume there are no bars for 10:05 or 10:10. All times in this example use the same clock convention.

A lookup for 10:10:00 has these outcomes:

The next bar at 10:15 is only five minutes from the target, while 10:00 is ten minutes away. The fallback still goes backward. That distinction matters if a developer informally describes the function as returning the “closest candle.”

Now add a strategy policy of your own: accept a fallback only if its opening timestamp is no more than five minutes before the target. The 10:00 result fails that policy because its age is ten minutes. The API lookup succeeded; the strategy's data-quality check did not. Those are two separate decisions.

The five-minute tolerance is an illustrative design choice, not an MT5 requirement or a recommended universal setting. A daily historical report and an intraday entry rule have different needs.

Read the returned timestamp, not just the index

Use iTime with the same symbol, timeframe and returned index to inspect the selected bar's opening time. Its shift is relative to the current bar, and a return value of zero indicates an error. Check for a valid lookup index before requesting the timestamp, then check the timestamp result too.

For diagnosis, retain the requested time, symbol, timeframe, lookup mode, returned index, actual opening time and error information. A record saying only “bar 12 found” hides the fact that two symbols can have different histories at the same index. The opening timestamp is the useful comparison key.

If your specification requires a candle whose opening time equals a particular scheduled timestamp, verify that equality explicitly. If it permits an earlier observation, verify the allowed age instead. These checks make the strategy requirement visible rather than leaving it implied by a function argument.

Opening-time age also says nothing by itself about when a bar's final high, low or close became available. Historical analysis must separately avoid using final candle values before the candle was complete.

Separate a genuine gap from data that is not ready

MetaQuotes explains in Organizing Data Access that a requested symbol/timeframe series may not yet be formed or synchronized, and data availability is not guaranteed at every call. Do not treat every failed lookup as proof that the market had no candle.

A practical diagnostic sequence is to confirm the intended symbol and timeframe, inspect available timestamps around the target, and check data readiness and error information before classifying the gap. Correct any mismatch between the event's clock convention and the history's timestamps as part of that review. Changing exact to false is a selection policy, not a repair for missing history.

For an entry rule, choose what “no usable observation” means before deployment: skip that decision, wait for data readiness, or accept a bounded earlier observation where the strategy permits it. Avoid an unlimited retry that eventually executes an old signal without rechecking its relevance.

For a time-based exit, there is an additional distinction: a number of observed candles is not necessarily a number of elapsed minutes. See time stops using bars or elapsed time before using a bar lookup as a clock.

A useful review exercise is to construct the small missing-interval example above in your own test data and record both lookup modes and the returned opening times. No terminal test is claimed here. The goal is to make the chosen policy observable: a missing candle should lead to a deliberate decision, not a quietly borrowed timestamp.