Timezones in Metatrader 5: unclear Python documentation

[bolau]

Hi folks,

the documentation for copy_ticks_range in the Python API says:

"When creating the 'datetime' object, Python uses the local time zone, while MetaTrader 5 stores tick and bar open time in UTC time zone (without the shift). Therefore, 'datetime' should be created in UTC time for executing functions that use time. The data obtained from MetaTrader 5 have UTC time, but Python applies the local time shift again when trying to print them."

In my opinion, this is unclear or misleading. The data obtained for example using copy_ticks_range is given in seconds since 1970 in the timezone of the broker (!), which can be a different time zone than the local time of your computer. For example, my local time is CET (UTC+1), but MT5 and the Python API display and provide data in EET (UTC+2), which is where my broker lives.

So, the documentation should probably call it "broker time" instead of "local time" to be more clear.

Additionally, it's misleading that Python applies the local time shift "to print them". That sounds as if the timestamps are timezone-aware, stored as UTC internally and only localized to broker time when calling print. Instead, the ticks are just integer numbers, representing unix timestamps in the timezone of the broker.

Hope that saves someone some time...

Best, Boris

[bolau]

By the way: is there a way to call the MQL5 DateTime functions from Python?

It would be nice to query the offset between UTC and server time, for example, as provided by this MQL function:

https://www.mql5.com/en/docs/dateandtime/timegmtoffset

Best, Boris

[Fernando Carreiro]

bolau: By the way: is there a way to call the MQL5 DateTime functions from Python? It would be nice to query the offset between UTC and server time, for example, as provided by this MQL function:

https://www.mql5.com/en/docs/dateandtime/timegmtoffset

Why? Just use the standard Python functions for that (e.g. "time.gmtime([secs])" ).

EDIT: The MQL functions "TimeGMTOffset" and "TimeGMT" is for getting GMT offset/time based on local time, not server time.

[bolau]

Hi Fernando,

you are right, timegmtoffset doesn't help here. But the question remains, how can I determine from Python the timezone that the MT5 server lives in, or its UTC offset?

Best, Boris

[Fernando Carreiro]

bolau: you are right, timegmtoffset doesn't help here. But the question remains, how can I determine from Python the timezone that the MT5 server lives in, or its UTC offset?

You can't! It is not even possible with normal MQL5 code! The reason, is that there is no way of obtaining information about which time zone a broker is using.

The only thing one can do, is when I tick arrives, to compare the time of tick with the current local time, and thus calculate the offset of the "current" situation.

However, this is not a foolproof way of knowing the timezone of past data, because of daylight savings and also in the unlikely but possible situation of the broker having changed time zone in the past.

In MQL there is the function "TimeCurrent()", but that is the equivalent of the time of the last incoming tick, of any symbol most recently updated, so the solution of using the tick time is the same.

[bolau]

That's crazy! Why would anyone provide non-UTC timestamps in an API without a way to find out which timezone they are in?
But it seems that the MQL function TimeTradeServer would do the trick, or am I misreading that as well:

https://www.mql5.com/en/docs/dateandtime/timetradeserver

Which doesn't help me any, since I'm on the Python side of things...

Best, Boris

[Fernando Carreiro]

bolau: But it seems that the MQL function TimeTradeServer would do the trick, or am I misreading that as well:https://www.mql5.com/en/docs/dateandtime/timetradeserver

Which doesn't help me any, since I'm on the Python side of things...

No! It would not, not even in MQL! That function is just an extension of "TimeCurrent()", allowing it to just simulate continuing to count time even when no ticks arrive. This is because TimeCurrent() pauses when no ticks are arriving. That is all it does.

[Anthony Eric Gillon Dawson]

bolau:

Hi folks,

the documentation for copy_ticks_range in the Python API says:

"When creating the 'datetime' object, Python uses the local time zone, while MetaTrader 5 stores tick and bar open time in UTC time zone (without the shift). Therefore, 'datetime' should be created in UTC time for executing functions that use time. The data obtained from MetaTrader 5 have UTC time, but Python applies the local time shift again when trying to print them."

In my opinion, this is unclear or misleading. The data obtained for example using copy_ticks_range is given in seconds since 1970 in the timezone of the broker (!), which can be a different time zone than the local time of your computer. For example, my local time is CET (UTC+1), but MT5 and the Python API display and provide data in EET (UTC+2), which is where my broker lives.

So, the documentation should probably call it "broker time" instead of "local time" to be more clear.

Additionally, it's misleading that Python applies the local time shift "to print them". That sounds as if the timestamps are timezone-aware, stored as UTC internally and only localized to broker time when calling print. Instead, the ticks are just integer numbers, representing unix timestamps in the timezone of the broker.

Hope that saves someone some time...

Best, Boris

Well it seems a bit of a mess... in my case ticks are coming out in proper Unix time UTC while M10, H1 and so on come out with a Unix timestamp shifted by broker time, in my case UTC + 2. As python thinks all Unix stamps are in UTC this causes all sorts of problems in trying to convert them back to UTC particularly if they are also subject to daylight saving! What's the best solution to convert these back to UTC with daylight savings awareness? Or perhaps I should just resample the tick data into M10 & H1 timeframes?