MetaTrader 4 Time is off by -5 hours in EA but only when using epoc time

 

I wrote a super detailed post about this problem on stackoverflow.com. Rather than re-create the entire thing here I'll just post the link:

https://stackoverflow.com/questions/59841733/metatrader-4-mql4-time-is-off-by-5-hours-but-only-when-using-epoc-time

Basically, I'm having a very specific problem with getting correct epoc time. When I get the time in Date Time format, everything is correct.

When I switch to epoc time, it goes crazy. All of the detail are in the post above.

MetaTrader 4 / MQL4 Time is off by -5 hours but only when using epoc time
MetaTrader 4 / MQL4 Time is off by -5 hours but only when using epoc time
  • 2020.01.21
  • Hakachukai
  • stackoverflow.com
I'm working with MetaTrader4 running in WINE in Ubuntu 16.04. I have a simple inline function that saves the time and various other info to a file using this line: Using the directive: will cause it to output the time in a Date Time format. Removing that directive will cause it to output time in epoc format. When it uses Date Time format ( by...
 
sys_time:2020.01.21 07:38:02.994394, sym:EURUSD, tick_time:2020.01.21 14:38:03, ask:1.1104, bid:1.110
sys_time:1579592538.630395, sym:EURUSD, tick_time:1579617738, ask:1.1105, bid:1.11041

These 2 values perfectly match. You are wrong thinking they are not.

Property strict only change the format, not the value.

Check the value returned by your bash command

date '+%s'

You are mixing local time and GMT time.

Epoch Converter
Epoch Converter
  • www.epochconverter.com
Epoch dates for the start and end of the year/month/day Convert seconds to days, hours and minutes What is epoch time? The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z). Literally...
 
Alain Verleyen:

These 2 values perfectly match. You are wrong thinking they are not.

Property strict only change the format, not the value.

Check the value returned by your bash command

date '+%s'

You are mixing local time and GMT time.


Thank you for that!

After reading, thinking and studying into Unix epoc time a bit more I found the problem.

Since I posted the original question over on stack overflow I also posted the answer over there.

The link is here: https://stackoverflow.com/questions/59841733/metatrader-4-mql4-time-is-off-by-5-hours-but-only-when-using-epoc-time
 
crazyh:


Thank you for that!

After reading, thinking and studying into Unix epoc time a bit more I found the problem.

Since I posted the original question over on stack overflow I also posted the answer over there.

The link is here: https://stackoverflow.com/questions/59841733/metatrader-4-mql4-time-is-off-by-5-hours-but-only-when-using-epoc-time
I don't want to argue but your answer on stackoverflow is plain wrong. There is no problem with TimeLocal(), but only with your understanding.
 
Alain Verleyen:
I don't want to argue but your answer on stackoverflow is plain wrong. There is no problem with TimeLocal(), but only with your understanding.

No worries, I'm not really into aurguing either.

However, if I am wrong I'd like to know how and why.


The whole basis of my claim / explanation is that Unix epoc time should be the same for everyone on Earth at all times. It does not respect timezone because it is based on an event that happened X amount of time ago.

If you drop a stone in a pond in London, wait 3.5 hours then ask 100 different people all over the World how long ago it was that the stone was dropped in the pond, they should all say "3.5 hours ago" regardless of that time they currently think it is.

Unix epoc works the same way. It is the answer the question: "How long ago was the event that took place on Jan 1st, 1970 00:00 UTC"?

That answer should be the same for everyone everywhere.


Which is why I know that something is wrong when TimeLocal() returns different epoc's based on my timezone. Changing my timezone changes its output.

Does that not break the very definition of what it means to be Unix epoc time? It should be the same for everyone everywhere.

 
crazyh:

No worries, I'm not really into aurguing either.

However, if I am wrong I'd like to know how and why.

Ok so let's explain it.

The whole basis of my claim / explanation is that Unix epoc time should be the same for everyone on Earth at all times. It does not respect timezone because it is based on an event that happened X amount of time ago.

If you drop a stone in a pond in London, wait 3.5 hours then ask 100 different people all over the World how long ago it was that the stone was dropped in the pond, they should all say "3.5 hours ago" regardless of that time they currently think it is.

Unix epoc works the same way. It is the answer the question: "How long ago was the event that took place on Jan 1st, 1970 00:00 UTC"?

That answer should be the same for everyone everywhere.


Which is why I know that something is wrong when TimeLocal() returns different epoc's based on my timezone. Changing my timezone changes its output.

Does that not break the very definition of what it means to be Unix epoc time? It should be the same for everyone everywhere.

The problem is your are making assumption, where did you see or read that TimeLocal() should return an "epoch time" ? Nowhere as it doesn't exist.

The documentation said :

Return Value

Value of datetime type

and about a datetime :

The datetime type is intended for storing the date and time as the number of seconds elapsed since January 01, 1970. This type occupies 8 bytes of memory.

No mention of Epoch right ? So TimeLocal() is the number of seconds since January 01,1970...local time (and not GMT as Epoch is).

TimeGMT() is similar but in reference to GMT, so this time it's equivalent to a reference to Epoch.

Don't interpret the documentation, read and understand it exactly as it is, an internal mql format.

Changing my timezone changes its output.

Fortunately, imagine the mess if the local time was not changing with the timezone.