Detecting Accurate Time in Metatrader 4 : a Real Nightmare ! (and a simple solution)

Different  trading strategies are used in forex mechanical trading and many of them rely on trading during specific hours to exploit inefficiencies that arise due to daily volatility/volume cycles. These trading systems are usually what we call “time sensitive”, systems that – in order to achieve results as seen on simulations – need to trade during very restricted time periods or they need to define certain criteria during a specific time. In Asirikuy we currently have two time sensitive systems – Kutichiy and Atipaq – which need to trade during very specific hours in order to achieve long term success. This is because both systems exploit breakout inefficiencies based on specific market hour cycles which are quite rigid as are the opening hours of the markets in which the different instruments are mostly traded. On today’s post I will talk a little bit about my journey in attempting to device an automated time setting criteria and how I finally managed to program something that was “simple” and worked with a very high level of robustness.

What is the problem with “knowing the time” in Metatrader 4 ? Our first problems comes up when we realize that different brokers have different time stamps on their candles meaning that for one broker hour 1 is a given candle while for another hour 1 is in fact hour 2, 4, 3, etc. What we need to do here is come up with a solution so that we can tell our broker that hour 1 is a given candle, independently of its own time stamp, we need to “shift” the time stamp of a given broker if it doesn’t match the time stamp we have on our backtests.

Obviously the first idea we get is to program some sort of way in which we can make the systems know their GMT offset and in this way each broker will be able to “correct” its time stamp so that it reaches the desired values. At first I thought that this solution was easy and robust as there are quite a few free and commercial systems that implement this “auto GMT” offset mechanism. The problem here is that the use of the Windows API to determine the actual GMT of the platform is not very robust as it depends on several different factors, sometimes – depending on windows version and user configuration – the variations caused by Daylight Time Saving (DTS) will not be detected appropriately and more often than not you will get with a far worse problem than in the beginning.

The nightmare becomes even more complicated when you realize that brokers themselves do DTS changes on their time stamps and even different DTS changes depending on whether the broker is in the US or in Europe. This DTS changes also bring problems to the Windows API as often the API will think that the broker is not in DTS or in DTS depending on the actual time zone used by the Windows user. After a lot of testing with many different approaches to this Windows API problem I realized that there was simply no easy way in which I could make this reliable.

The only thing I found plausible was to get the actual GMT zero time from a website so that the systems could compare, calculate offsets, etc, independent of the Windows time setting. The problem with this approach was the need for an http “get” code within a dll, such codes are often unstable within Metatrader 4 and can cause the platforms to crash. After trying different code variations I decided that this approach wasn’t robust enough as it would compromise platform stability.

So after I had almost given up hope to find an automated solution to time setting while we move to Metatrader 5 (which makes this much easier as the broker GMT offset becomes an environmental variable) I had an idea which was very simple and in fact works in a very robust and reliable manner. A “bullet proof” solution to the auto time setting problem. Since the data we use for the backtests in Asirikuy is one minute Bid data obtained directly from Alpari UK, it was reasonable to think that Alpari UK’s time stamps match the backtesting data. After emailing Alpari I received an affirmative answer confirming that the backtests do preserve Alpari UK’s time stamp from 2000. So the solution is actually simple, compare your platform’s time stamps with Alpari UK’s and shift them as necessary to match.

The robust solution comes in the form of an EA resting on an Alpari UK demo platform which continuously sends a “signal” to the other broker’s platform indicating Alpari UK’s time stamp. The other platform then compares this information against its own and determines the offset it needs. Of course due to tick differences, etc the offset signal is intermittent but since the offset doesn’t change frequently (just twice per year) the average refreshing rate of about 3 to 4 times per minute is good enough.  After the first refreshing the other broker’s platform always keeps the last known offset in memory so that it uses this offset when it doesn’t find the signal.

This solution was coded to be extremely robust. Signals are only received between an hour’s 5 and 55 minutes so that no potential problems due to hour changes cause the wrong offset to be generated. Additionally the “signals” are eliminated on every tick -or EA reloading – so that the possibility of getting a bad offset due to “old signals” is completely eliminated. If anything happens to the Alpari platform, no problem, the old signal offset is used and the user is informed about the fact that no refreshing has been received after a few hours. When the Alpari UK platform is restored the signals are received again without any problems. The EA can also send signals to up to 10 brokers at the same time so the resource usage of this platform is kept at the bare minimum.

This approach allows us to match the Alpari UK time stamp – which matches the backtest’s – without needing to worry about anything related with the GMT offsets of the platforms (the above image shows the offset is adequately detected in Atipaq on a broker which has a +1 offset relative to Alpari UK). When Alpari UK shifts this will be detected and the shift will be sent to the new broker and saved as the latest known offset. The solution is extremely robust and keeps the EA in “time-sync” without any complications and without compromising the stability and robustness of the platforms. Better yet, there is no concern at all with DTS or the appropriate setup of the Windows timing mechanism.

I have been testing this approach for the past few weeks (in which there was a DTS change) and I can now confirm that the approach is as robust and good as I initially thought. This new way to “auto calculate” timing will be included on the EA update released this week on Asirikuy as well as some other surprises that will greatly improve our current EA implementations. If you would like to learn more about Atipaq, Kutichiy and how you too can program your own expert advisors geared towards long term profitability please consider joining Asirikuy.com, a website filled with educational videos, trading systems, development and a sound, honest and transparent approach to automated trading in general . I hope you enjoyed this article ! :o)

Print Friendly, PDF & Email
You can leave a response, or trackback from your own site.

Leave a Reply

WordPress › Error

There has been a critical error on this website.

Learn more about troubleshooting WordPress.