Solving the Time Setting Problem: Finally a Reliable, Error-Free, Completely Automated Time Detection Solution for MT4 (and 5)

Within the past year one of our main concerns in Asirikuy has been the adequate detection of broker offsets for time sensitive trading systems. In the past I have written about the solutions I had devised including a solution using an Alpari UK time setting EA and the first appearance of the NTP idea suggested within the community. The problem we had was not only about getting an accurate time stamp for our systems but about being able to compare such time stamps with the broker time of Alpari UK from where our backtesting data actually derives. After a lot of work, debugging, stability tests and reliability tests I am very happy to say that we have finally been able to develop a completely reliable NTP based solution for the automatic time detection within our systems. Through the following post I will a little bit about this development process, what we have arrived to and why this will greatly benefit our current and future developments within Asirikuy.

The problem with time in MT4/5  is fairly simple and anyone who has been trading the Forex market for a while -especially if they have developed time sensitive strategies – knows what I am talking about. The MT4 terminal has a different time stamp – depending on the broker’s configuration – and therefore what might be 2 PM for one broker might well be 11 AM for one and 4 PM for another. When you want to develop a system that trades – for example – an inefficiency based on the London open, it becomes vital to know when the London open is irrespective of your broker.

The simplest solution to do this – and what most commercial systems do – is rely on the reading within your system’s clock to determine what time it is on the UTC clock and then use this information to determine the correct timing of your entry. The problem with this – and why I have never implemented this solution – is that it is very vulnerable to tampering with the computer’s local clock so if there are any changes within your local clock you will see them reflected on your UTC time and therefore you will get inaccurate timing. Long story short, looking at the local clock is NOT a robust solution and therefore it became important to rely on an external source to do the clock updating.

This is when I started to play with the idea of using an NTP approach – which was suggested by an Asirikuy members – as this allows us to effectively synchronize with servers which have accurate time and to adequately sync our timing with that of the servers to ensure that we are in fact looking at the appropriate UTC time and adequately calculating our offset from Alpari UK’s time (also taking into account any DST changes that may be in place automatically).

At first my NTP implementations turned out to be very unstable and MT4 crashed repeatedly whenever any small error started to arise. After looking deeply into the issue I realized that I wasn’t probably using the best NTP Delphi components and I decided to change to a more reliable delphi NTP implementation which proved to have a lot of added stability (due to its much better errors handling). During the past few weeks I have tested the DLL which came out of this development process and – after adding adequate error handling of timeouts, disconnections, etc – we arrived at an NTP implementation that doesn’t crash and adequately sends reports of any inadequate time detections to the MT4 EA.

Added to this I also tested the MT4 EA implementation which calls the DLL, ensuring that no losses in synchronization happened, multiple broker stability existed and multi platform, multi instance usage didn’t cause any problems.  After this I also added random server selection to the NTP DLL and a quadruple server safety check to ensure that we wouldn’t use any timing information if it didn’t match perfectly between all NTP servers which got requests. The result in the end is an extremely stable MT4/Delphi DLL implementation which doesn’t crash, doesn’t give wrong offsets, adequately handles errors and adequately handle multi-platform, multi-instance implementations.

If you want to know how deeply I tested this implementation I could say that – in order to avoid some of the problems we had with the Alpari UK time setting EA – I have tested this MT4/Delphi DLL combination on a 10 broker 60+ instance setup and no crashes or wrong offsets have been given, even across daily changes, reboots, forceful application terminations, forced restarts, etc. The current NTP implementation is therefore the culmination of a battle with adequate time setting in which we have finally won with the usage of a very simple and yet reliable Delphi DLL that allows us to adequately get UTC time, breed the Alpari UK hour and compare it to any particular broker setup.

From this weekend Asirikuy members will be able to forever say “goodbye” to our old Alpari UK time setting EA and “hello” to the new NTP based implementation which warrants totally automatic, error-free time adjustments for our trading needs without the need to load any additional systems, terminals, etc. I will release a video this weekend explaining this new implementation, the coding within the DLL and the tests done to confirm the platforms reliability. If you would like to learn more about my work in automated trading and how we solved this time setting problem with sensitive systems 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)

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

4 Responses to “Solving the Time Setting Problem: Finally a Reliable, Error-Free, Completely Automated Time Detection Solution for MT4 (and 5)”

  1. Daniel-

    Great stuff and very much something we need! Keep up the great work!

    Chris

    • admin says:

      Hello Chris,

      Thank you for your comment :o) This is definitely a great step and – as you say – something we definitely needed to ensure much more reliable execution. Thanks again for stopping by !

      Best Regards,

      Daniel

  2. James says:

    Hello,

    This post is from three years ago
    Is your indicator ready?
    May I test it?
    Please contact me.

    James

    • admin says:

      Hi James,

      This evolved into the F4 framework which we developed at Asirikuy to contain time correction libraries to allow for trading/back-testing without worrying about this problem. The F4 framework is available by joining the Asirikuy community (asirikuy.com/join.htm). Thanks for commenting,

      Best Regards,

      Daniel

Leave a Reply

WordPress › Error

There has been a critical error on this website.

Learn more about troubleshooting WordPress.