MetaQuotes-Demo: matching M1/H1 gaps at 23:00 and 00:00 on XAUAUD/XPTUSD, 15–17 Sep 2026
I am investigating historical bar availability on MetaQuotes-Demo...
I wouldn't waste much time analyzing data from a Metaquotes Demo account. That data is notoriously unreliable.
I use a Metaquotes Demo account only for code development (staying ahead of the Build curve, so to speak) and verifying basic code functionality.
Hello,
I have a read-only update relevant to the time-basis question in my original post. These observations are from 22 September 2026, using MetaQuotes-Demo, MT5 terminal build 6198, Python 3.14.6 and MetaTrader5 package 5.0.6070. The earlier bar-gap observations used build 6191 and remain a separate issue.
For XPTUSD, symbol_info_tick returned:
time = 1790096243
time_msc = 1790096243983
Interpreting time_msc as a UTC epoch yields 2026-09-22T16:57:23.983Z. The PC wall-clock readings bracketing the request, expressed as UTC, were 2026-09-22T13:57:25.158651400Z and 2026-09-22T13:57:25.175054200Z. Recorded NTP probes showed a maximum absolute offset of about 0.280447 seconds, but were unauthenticated and do not certify the PC clock.
Two copy_ticks_from requests used count=64 and the package's COPY_TICKS_ALL value:
- integer argument: 1790096243;
- UTC-aware datetime argument representing exactly the same value: 2026-09-22T16:57:23+00:00.
Both returned identical five-row arrays, including one complete eight-field match of the live tick. Their time_msc values were 1790096243776, 1790096243824, 1790096243880, 1790096243933 and 1790096243983. A PC-anchored request reached the 64-row limit without that live tick; this was not an exhaustive history search.
Complete samples for AUDCHF, NOKSEK and XAUAUD in an earlier, budget-interrupted run also showed matching integer/datetime arrays and a live-tick match. Those samples and the separate XPTUSD run were not simultaneous. No timestamp offset was applied and these reads sent no orders. Agreement between APIs does not establish UTC correctness or feed freshness.
The Python reference describes returned tick/bar times as UTC:
https://www.mql5.com/en/docs/python_metatrader5/mt5copyticksfrom_py
The MQL5 book describes server time received with ticks and used on chart axes:
https://www.mql5.com/en/book/common/timing/timing_local_server
Could MetaQuotes or someone with a documented server-specific reference clarify:
- On this server and version combination, do the time/time_msc fields from symbol_info_tick and copy_ticks_from encode absolute UTC, server civil time, or another convention?
- If a conversion is required, what exact rule and validity interval applied on 22 September 2026, including the relevant DST transitions and any symbol-specific differences?
- If these fields are intended to be absolute UTC, what supported explanation or remedy addresses the observed discrepancy?
- Separately, does that convention also apply to historical bar timestamps and quotation/trading session times in the original 15–17 September question?
I am requesting the documented convention, without assuming that the approximately three-hour difference proves an offset or a platform bug. Thank you.
On this server and version combination, do the time/time_msc fields from symbol_info_tick and copy_ticks_from encode absolute UTC, server civil time, or another convention?
"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. Data received from the MetaTrader 5 terminal has UTC time." (https://www.mql5.com/en/docs/python_metatrader5/mt5copyticksfrom_py).
"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. Data received from the MetaTrader 5 terminal has UTC time." (https://www.mql5.com/en/docs/python_metatrader5/mt5copyticksfrom_py).
@MetaQuotes, please update the official MQL5 documentation. The erroneous documentation is causing confusion in multiple threads regarding Python time.
Forum on trading, automated trading systems and testing trading strategies
MetaQuotes-Demo: matching M1/H1 gaps at 23:00 and 00:00 on XAUAUD/XPTUSD, 15–17 Sep 2026
Alain Verleyen, 2026.09.22 17:38
The problem is the documentation is wrong. The data returned from MT5 has the broker server time zone, not UTC.Thank you, Alain, for clarifying the server-time interpretation in reply #4.
For MetaQuotes-Demo specifically, could you point us to a documented UTC offset and DST rule covering 15–23 September 2026? Our current question concerns terminal build 6198 and Python package 5.0.6070; the 15–17 September bar-gap capture used build 6191.
Could you also clarify whether that rule applies equally to Python symbol_info_tick/copy_ticks_from time fields, historical M1/H1 bar-open timestamps, and SymbolInfoSessionQuote/Trade session times?
One separate issue remains for XAUAUD and XPTUSD: both M1 and H1 had no returned bars from raw 23:00 through 00:59, while the captured weekday sessions were 00:00–23:00. If these share the same time basis, was raw 00:00–00:59 a scheduled closure on those dates, or should history availability be checked another way?
If the server rule or historical calendar is not published, which supported source or verification procedure should we use? We have preserved the raw timestamps and applied no correction. Thank you.
Thank you, Alain, for clarifying the server-time interpretation in reply #4.
For MetaQuotes-Demo specifically, could you point us to a documented UTC offset and DST rule covering 15–23 September 2026? Our current question concerns terminal build 6198 and Python package 5.0.6070; the 15–17 September bar-gap capture used build 6191.
Could you also clarify whether that rule applies equally to Python symbol_info_tick/copy_ticks_from time fields, historical M1/H1 bar-open timestamps, and SymbolInfoSessionQuote/Trade session times?
One separate issue remains for XAUAUD and XPTUSD: both M1 and H1 had no returned bars from raw 23:00 through 00:59, while the captured weekday sessions were 00:00–23:00. If these share the same time basis, was raw 00:00–00:59 a scheduled closure on those dates, or should history availability be checked another way?
If the server rule or historical calendar is not published, which supported source or verification procedure should we use? We have preserved the raw timestamps and applied no correction. Thank you.
It applies to all functions and all symbols data. MT5 is using broker server time for all these data.
MetaQuotes-Demo is a server for technical testing. Use a a real broker account if you want reliable data.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Hello,
I am investigating historical bar availability on MetaQuotes-Demo, MT5 build 6191, for XAUAUD and XPTUSD.
A native MQL5 script made one date-range CopyTime request per symbol/timeframe/window: eight calls in total, with no retries. Both M1 and H1 were queried for these inclusive raw timestamp ranges:
These labels are not asserted to be UTC; no timezone correction was applied.
The same result occurred for both symbols in both windows:
All calls reported error 0. SERIES_SYNCHRONIZED was 1 after each call; it was 0 before the first M1 call for each symbol. A previous H1 capture showed the same gaps.
A separate two-pass capture using SymbolInfoSessionQuote and SymbolInfoSessionTrade returned weekday sessions 00:00–23:00 for both symbols. I understand that a current weekly schedule does not establish the historical calendar, and missing returned bars do not prove that no ticks existed.
Could MetaQuotes or someone with a documented server-specific reference clarify:
The evidence attachment contains timestamp and session observations, with no account identifiers, prices or trading logic. This is a request for clarification, not a confirmed platform bug report.
Thank you.