Certainly one of the biggest problems we’ve had with trading systems during the past year has been the adequate determination of time sensitive parameters for systems which need to enter trades at very specific times of the day. Throughout the year we have used several solutions for this problem ranging from simple broker to broker comparisons to the implementation of an Alpari UK time logger EA which uses file writing/reading in order to keep another MT4 instance adequately synchronized with the Alpari UK time stamp. Within the following paragraphs I will be talking to you about a new solution I have implemented dealing with NTP (Network Time Protocol) synchronization which seems to be very robust and able to adequately calculate Alpari UK time stamps without the problems of the other methods we have tried.
If you read this article, after many months of trying to come up with reliable implementations for the determination of time parameters for our MT4 experts we finally came up with a file writing/reading mechanism which allowed us to adequately synchronize an MT4 platform with the Alpari UK time stamp without the risk of time signature errors or other such problems. This implementation uses an EA loaded within an Alpari UK demo account which generates a “time stamp” containing file which is then read by the target MT4 EA. The EA then uses this timing information and its own broker timing to determine the offset and its time sensitive parameters.
–
–
This solution has had a lot of success in many areas, of particular importance is the fact that this implementation has solved the time setting problem and we can now assure that all people who use this mode of synchronization are implementing the exact same timing characteristics. However there are several problems of this implementation which cannot be easily sorted out such as the generation of large amounts of harmless file write/read errors (created when both experts attempt to write/delete a file at the same time) and other problems which are simply inherent to this solution (such as the use of an additional MT4 platform).
In order to solve these problems I have listened to the suggestions of a few forum members who thought an NTP solution would be best as it would give the highest level of reliability for time determination without the need for an additional Alpari UK platform or the generation of large numbers of errors. This implementation requires the MT4 platform to synchronize its time with that of an NTP server (which has reliable timing) then using the universally obtained time to calculate the Alpari UK time stamp taking into account the times in which Alpari UK changes DST, etc.
Certainly one of the main objective of this implementation would be to contain all the advantages of the Alpari UK time setting EA approach so it becomes important to provide a high level of robustness against possible things that may go wrong. To guarantee this I have implemented a very robust approach which I believe fulfills all the needed characteristics. This approach first synchronizes the platform’s time with an NTP server (stopping the EA if it doesn’t), then using UTC (Coordinated Universal Time, and yes, the order of the letters does not match) in order to internally generate the adequate Alpari UK timing information (which makes it independent of system time zone).
I have tested the approach on several different VPS and attempted to make it “fail” by changing system time, time zone, etc without success. This approach then allows us to easily determine the adequate offset of any broker without the need to have another Alpari UK platform loaded (which increases memory requirements) and without the generation of any errors. In order to also make this syncing calling very stable I have also moved the time synchronization aspects to a separate delphi executable with all the adequate functions being called from a delphi DLL, this also ensure that this time syncing approximation will remain compatible with MT5.
This new time setting implementation will be released within the next few weeks – coded inside all relevant systems – to Asirikuy members but it is important to mention that the previous Time Logger EA based implementation will remain as an option in the experts so that users can choose whichever they like better. Certainly this NTP based approach makes time detection much easier, at least as reliable as the Time Logger EA and error free :o)
Of course if you would like to learn more about my work in automated trading and how you to can earn a true education regarding automated trading and the development of strategies with sound trading tactics 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)
Another joy of dealing with time on MT4 is how un-atomic it is.
Let’s say you want the closing price of the previous candle, so you do the following.
datetime time = iTime(“EURUSD”, PERIOD_H1, 1);
double price = iClose(“EURUSD”, PERIOD_H1, 1);
Unfortunately, if time happens to be 5:59:59, then based on my testing you have a 1 in 18 chance that your close price is associated with the 6 o’clock candle and not the 5 o’clock candle.
Oops!
Hello Brian,
Thank you for your comment :o) Metatrader is definitely – as you call it – as un-atomic as it gets. Using fine time stamps in MT4 is not worth doing since instructions are executed on a per-tick rather than a per-time-unit basis. This is however fixed in MT4 where EA code is executed either on every tick or on every time unit allowing the execution of instructions with much more adequate precision. However, due to the whole MT4/5 dealing structure it will always be the case that order execution, etc will have to work on a +/- 10 second basis. If the execution of orders is critical under a certain time stamp down to the ms or larger precision then adequate direct broker connections through a Currenex (or similar API) would be necessary. Thank you very much again for your comment :o)
Best Regards,
Daniel