## The Time Array Mismatch Problem: A Dark MT4 Secret Comes to Light

When you program a strategy it is clear that one thing is backtesting and another very different one is live trading. I have written a few posts in the past about the things traders need to take into account when building trading strategies for reliable live execution and today I will be talking about a problem we found last week in Asirikuy (thanks to our systems’ screenshot-on-trade saving functionality) which shows how careful a person must be when designing a strategy for live trading execution. Within the following few paragraphs I will be describing the issue of mismatching time arrays and how this can cause significant problems for systems which are time sensitive (for example systems which set pending orders or enter trades at a given hour).

So what is the time mismatch array problem? In Metatrader 4 there are several functions which return the values assigned to the different variables inherent to each candle. For example if within mql4 you call the Close[1] function it will return the close for the first bar in the past while Open[0] – for example – returns the open value for the currently running candle. When we program trading systems we routinely use these functions to run our strategies since the OHLC values of candles are the heart of any technical analysis strategy. Even indicator strategies make extensive use of this type of functions (even if the only use Volume[]) as every analysis of price clearly depends on price itself.

Now what happens is that these function do not have any type of “tie” to the actual hour of the broker server (called through the Hour() function) meaning that on some times – usually right at the end of a candle during low liquidity – the hour will shift but the candle arrays will remain on the last one. For example the Hour() function value can change to 4 but the OHLC values are not currently set to the values of the new candle as zero but to the values of the last candle (hour 3). If you have a strategy which seeks to – for example – setup a range and pending orders at 4 based on Close[15] the strategy will be looking at what in reality is Close[16] as there is a mismatch between the time array (which keeps Hour()) and the candle array values of the candle.

In reality this means that you will enter the trade at the right time (Hour() is detectedÂ appropriately) but with the wrong information (since the array candle information is not shifted). The solution to the problem – which is implemented on an update to time sensitive Asirikuy systems which will be released tomorrow – saves the value of Time[1] on the hour before the target market analysis hour and then compares this value with Time[2] once we change to the actual analysis time. If there is a mismatch then the system will show an error and avoid any trading. Note that the error usually lasts for only one or two ticks (as the candle array syncs) which means that trades are usually taken just a few seconds later.

Is this error common? Certainly this was the first question I decided to ask after I learned about its potential effect. The answer after loading the modified systems on my live platforms was evident. Within a 20 hour period I saw at least 10 different occurrences of the error distributed across at least 4 brokers meaning that the error is indeed quite common and therefore the generation of some broker dependency due to this random problem is almost warranted unless there is some method to correct it from happening (as detailed above). Since trades had always been entered at the right time we had actually never noticed this but thanks to the judicious analysis of an Asirikuy member and the use of our screenshot saving functionality we were able to catch the problem right away and modify our systems accordingly to tackle it.

Note however that this problem only affects systems that depend on a particular market hour to carry out some action based on price values (which includes indicators) and will not affect systems that execute non-candle array based code (like for example some other calculations dealing with account balance, open trades, etc) or systems that do not depend on any particular hour for action. This problem however is bound to introduce significant broker dependency in the medium and long term as brokers will show this error with different frequency and across different days of the week. This potentially explains some of the large broker dependency issues of systems like Sapaq which have been observed within the past few months.

If you would like to learn more about system coding and how you too can learn how to code, evaluate and analyze strategies based on sound trading conceptsÂ please consider joiningÂ Asirikuy.com, a website filled with educational videos, trading systems, development and a sound, honest and transparent approach towards automated trading in general . I hope you enjoyed this article ! :o)

### 7 Responses to “The Time Array Mismatch Problem: A Dark MT4 Secret Comes to Light”

1. Maxim says:

Daniel,

Thanks a lot for letting know about the problem existence.
This proves that a community-traded systems have a potential of providing additional level of robustness once again.

Maxim

2. McDuck says:

My hat off. Impressive work.

3. Caner says:

Daniel,

It’s good to learn that this is a common problem. I began to plan about changing my broker or vps or something, thinking that this was happening to me only.

Caner

4. Franco says:

Thanks Daniel!

This is horrific to say the least, does this problem only persist in live trading or can we find it in backtesting also?

• Caner says:

Hi Franco,

I think, this type of thing cannot happen in backtesting, because this is a realtime related issue. Time changes to next hour but there is no tick, so no new bar. EA looks to time for evaluating Close[1], but actually it is looking to Close[2] according to time. This cannot happen in backtesting.

Caner

• Caner says:

Sorry, I mean no tick for new bar.

Caner

5. Brian says:

This happens frequently enough that I recommend you don’t bother showing an error. In fact, all you have to do once you identify the problem is simply throw out your calculations that have the atomic error and immediately recalculate. This way, you don’t even lose 1 tick for your trade – at most you’d lose a few milliseconds for the additional calculations.

Or, at least, that’s what I did :-)