GMT and offset calculations
[...] Why didn't you provide functions for being able to add or subtract dates and time?
MT4 datetimes are simple Unix-style timestamps measured as seconds since 1/1/1970. Therefore, subtracting one date from another gives the number of seconds between them. Adding a number of seconds/days/weeks etc to a date is also equally simple. The only place where things potentially get tricky is month-based arithmetic.
There are lots of previous topics on this forum dealing with GMT. There are basically four routes:
- Ask the user to provide the offset.
- Query the Win32 API function which returns the current offset value.
- Query the Win32 GetSystemTime() function and work out the offset by comparing against with the local time.
- Or, as some commercial EAs do it, get the GMT time/offset from the remote server which they also use for licensing.
It really frustrates me that the MQL4, does not provide for time calculations, or even to say the least, the abilityt o pinpoint a specific time based off of GMT.
Surely there must be more convenient and less cumbersome methods for time calculations than the number of seconds from 1970 ? !
- Query the Win32 API function which returns the current offset value.
- Query the Win32 GetSystemTime() function and work out the offset by comparing against with the local time.
These rely on local computer time...? So, won't that be unreliable? (the clock will not necessarily be auto-synced).
Surely there must be more convenient and less cumbersome methods for time calculations than the number of seconds from 1970 ? !
can you imagine any simpler method? I can't.
These rely on local computer time...? So, won't that be unreliable? (the clock will not necessarily be auto-synced).
...That's why commercial EAs tend to get a time signal from their licensing server. However, there is a reasonably reliable alternative route:
- Read the GMT offset provided by the computer's regional settings. The computer's local clock may be out, but the timezone settings are likely to be reliable. (If not, the user is going to run into all sorts of other problems.)
- Work out the offset between broker time and local time, to the nearest 30 minutes (to allow for countries such as India using timezones such as GMT+05:30). Provided that the user's clock is out by a relatively small margin, and assuming that the broker's time is correct, that gives you the ability to calculate accurate local time.
- Modify the accurate local time by the GMT offset.
It's a tried-and-tested method which uses a small amount of memory for representing datetimes (4 bytes), and which makes date arithmetic easy for any unit smaller than a month.
...That's why commercial EAs tend to get a time signal from their licensing server. However, there is a reasonably reliable alternative route:
- Read the GMT offset provided by the computer's regional settings. The computer's local clock may be out, but the timezone settings are likely to be reliable. (If not, the user is going to run into all sorts of other problems.)
- Work out the offset between broker time and local time, to the nearest 30 minutes (to allow for countries such as India using timezones such as GMT+05:30). Provided that the user's clock is out by a relatively small margin, and assuming that the broker's time is correct, that gives you the ability to calculate accurate local time.
- Modify the accurate local time by the GMT offset.
I see. But if local computer time is completely off (I mean by hours) then this will fail. I imagine that's a rare case, but I wouldn't be surprised if it's not that rare.
How about getting some known time from the net via wininet.dll and comparing that to the server time? Or maybe just do that once at EA start, compare it to the local computer time (which would make it 'known').
I see. But if local computer time is completely off (I mean by hours) then this will fail. I imagine that's a rare case, but I wouldn't be surprised if it's not that rare.
How about getting some known time from the net via wininet.dll and comparing that to the server time? Or maybe just do that once at EA start, compare it to the local computer time (which would make it 'known').
Given how long the installation instructions for most EAs are, I'd be tempted simply to add a step reading "Make sure your computer's clock is correct".
There are plenty of public time servers on the internet, but talking NTP (RFC 1305) from MT4 is not going to be much fun. What many commercial EAs do is run a page on their own web server which returns some MT4-friendly representation of the time over HTTP.
Given how long the installation instructions for most EAs are, I'd be tempted simply to add a step reading "Make sure your computer's clock is correct".
Personally, I'd prefer your first suggestion - adding an extern to input the server's GMT offset. But I know a lot of forum members are looking for ways to do 'everything' automatically (e.g. the 'Automatic Magic Number' thread, etc.), so they won't like that solution...
It really frustrates me that the MQL4, does not provide for time calculations, or even to say the least, the abilityt o pinpoint a specific time based off of GMT.
Someone out there must have built a tool that calculates a targeted time based off of GMT offset and DST evaluations. Please share with me or tell me what it would cost me to aquire.
My question to MQL4 is why didn't you provide a TimeGMT function? Why didn't you provide functions for being able to add or subtract dates and time?
If it's any consolation, The developer of MQL5 fortunately address this. :)
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
It really frustrates me that the MQL4, does not provide for time calculations, or even to say the least, the abilityt o pinpoint a specific time based off of GMT.
Someone out there must have built a tool that calculates a targeted time based off of GMT offset and DST evaluations. Please share with me or tell me what it would cost me to aquire.
Problem:
An event in the market takes place at 2 different times on PAC time. I am attempting to write code for it so that when this time occurs, I can fire off a trade. It would work, but the problem is that not all servers are on GMT or on Eastern. AND certainly not all customers are on the same timezone as PAC. So the program is trashed when trying to run on Mountain, or any other timezone for that matter. As it is, PAC users localtime is still an offset from server time based on servers settings. So still this remains an issue.
My thought was to establish GMT by having user provide me with their GMT offset, but even that will change based on leap year and DST. If I could get the GMT value, we would be half way there. By establishing GMT, then getting the comparing it to the server time, we would then know the users time, the GMT and the server time.
My question to MQL4 is why didn't you provide a TimeGMT function? Why didn't you provide functions for being able to add or subtract dates and time?
If I can provide a time say TimeLocal() to a function like DiffTime(TimeLocal(), TimeGMT()) it would be so much easier to establish the actual time and date when to fire these trades.
I have more than 5 strategies alone that could heavily benefit from tools that handle time better than current.
While keeping this in mind, there is also the different way that different countries display time. Another feature this product could use that I am sure, many strategies could benefit from.
If you have a tool that handles getting times based on GMT or offsets, please let me know. It shoudl take into consideration GMT, DST and leap year conditions. It should be able to add or subtract time and dates. For example, I might want to do the following:
UserGMTOffset = TimeGMT() - TimeLocal(); // returns GMT offset of local time
ServerGMTOffset = TimeGMT() - TimeCurrent(); // returns GMT offset of servers time
TargetGMTOffset = ("yyyy.mm.dd.hh:mi", GMTOffset, TimeGMT());
// returns GMT offset of specified time.
ServerTargetTime = TimeGet(TargetGMTOffset /* Time to trade */, ServerGMTOffset)
// ServerTargetTime is the resulting time of adjustment from TargetGMTOffset
// and ServerGMTOffset. The result should generate a new time that is relative to the
// server processing the EA.
Just one point of curiosity, how could so many automations exist out there that are based on time and price values and yet no one in the industry has addressed this issue. Either this is pure insanity or a really good explanation of why so many EAs fail.