MetaQuotes-Demo: official historical UTC/DST mapping by symbol, 2021–2026

[gametiny]

Hello MetaQuotes team,

Could the team responsible for MetaQuotes-Demo market history confirm the authoritative conversion from native MT5 timestamps to actual UTC for 2021–2026? We need reproducible historical/live alignment while retaining MetaQuotes as our data source. Please distinguish a confirmed server policy from an empirical estimate or a general rule used by other brokers.

Scope

- Server: MetaQuotes-Demo, MetaTrader 5. Current terminal build: 6254; installed Python MetaTrader5 package: 5.0.6180.

- Historical data: M1, M15, H1 and H4. Retained raw timestamp labels collectively span 2021-06-08 04:56:00 through 2026-09-04 18:34:00, plus current seed/history observations through 15 October 2026. These labels are deliberately not asserted to be UTC.

- Symbols: AUDCAD, AUDCHF, AUDJPY, AUDNZD, AUDSGD, AUDUSD, CADCHF, CADJPY, CHFJPY, EURAUD, EURCAD, EURCHF, EURGBP, EURJPY, EURNZD, EURUSD, GBPAUD, GBPCAD, GBPCHF, GBPJPY, GBPUSD, NZDCAD, NZDCHF, NZDJPY, NZDUSD, USDCAD, USDCHF, USDJPY, XAGUSD, XAUUSD.

Questions requiring provider confirmation

1. For this server, are MqlRates.time, MqlTick.time and MqlTick.time_msc actual UTC epochs, or server wall-clock labels encoded numerically as epochs? Does this differ between native MQL5 and Python copy_rates_range/copy_ticks_range/symbol_info_tick? Please state the time domain of query bounds separately from that of returned timestamps.

2. Please provide the effective UTC offset and DST intervals for each applicable symbol over 2021–2026, including the exact transition instants and any exceptions. A shared schedule with an explicit list of covered symbols is sufficient if they all use the same mapping. Please explicitly confirm EURUSD, XAUUSD and XAGUSD. Session-opening/closing hours alone cannot establish this mapping.

3. For each interval, please specify UTC start inclusive/end exclusive, corresponding raw timestamp boundaries, offset in seconds, and the conversion formula (for example, actual_UTC = raw_epoch - offset_seconds, only if that is the correct convention). Please include any feed/server migrations, instrument-specific history conventions, rule versions or periods for which no reliable mapping is available. For the remainder of 2026, please distinguish a planned policy from already observed historical behavior.

4. Can downloaded history be relabeled retrospectively, normalized using the current DST offset, or differ by download date, server build or API version? If so, how should previously retained raw downloads be interpreted, and which historical intervals/symbols are affected?

5. Could you supply at least one independently UTC-anchored tick/bar sample on each side of the applicable March and October/November transitions? Our comparison dates include 2022-03-14, 2022-03-28, 2022-10-31 and 2022-11-07. Matching server labels and OHLC alone does not prove their UTC meaning.

Concrete current observation

On 2026-10-15, one read-only EURUSD symbol_info_tick observation was bracketed by host UTC 16:42:30.156632Z and 16:42:30.158560Z. The SDK returned time_msc = 1792093350048, whose numeric UTC rendering is 2026-10-15 19:42:30.048Z. Thus the raw number was approximately 10,799.89 seconds ahead of the host reading. XAUUSD and XAGUSD showed approximately the same three-hour difference. Windows Time was running; contemporaneous read-only NTP comparisons were approximately 51–52 ms. Quote age and host clock uncertainty remain, so this is an observation, not a certified historical offset rule.

We also compared 44 native M15 bars across EURUSD/XAUUSD/XAGUSD on the four historical dates above with retained downloads: sampled OHLC and raw labels matched. This supports source consistency but supplies no independent UTC anchor.

The Python API documentation describes UTC. Please clarify how that statement applies to this observed server behavior:

- https://www.mql5.com/en/docs/python_metatrader5/mt5copyratesrange_py

- https://www.mql5.com/en/docs/python_metatrader5/mt5copyticksrange_py

- https://www.mql5.com/en/docs/dateandtime/timegmt

- https://www.mql5.com/en/book/common/timing/timing_gmt

TimeGMT in the Strategy Tester equals simulated server time, so it cannot independently establish the historical UTC mapping.

A dated official statement or a table with the following columns would be ideal:

symbol_or_explicit_symbol_group, effective_from_utc, effective_to_utc_exclusive, raw_from, raw_to_exclusive, utc_offset_seconds, conversion_rule, exceptions, source_or_policy_version

If MetaQuotes does not retain or guarantee this historical mapping, please state that explicitly and identify the responsible technical channel or data-feed authority that can confirm it. A current offset or an assumed European/US DST calendar is insufficient for validating the older archive.

Thank you.

[Alain Verleyen]

Forum on trading, automated trading systems and testing trading strategies

MetaQuotes-Demo — MT5 Python Historical Order and Deal Coverage

Alain Verleyen, 2026.10.15 14:53

Ask your AI agent to READ the forum BEFORE posting.

It has been asked and answered a lot of times on this forum.

[gametiny]

Thank you. I have read the linked discussion (517974), including the clarification that returned labels use broker server time and that there is no direct historical-offset function. The remaining issue is the effective MetaQuotes-Demo history policy, rather than how to format a datetime.

We now have a small native reproduction which may help distinguish history-source issues from conversion errors. A fresh portable MT5 data directory was created without copying history, profiles or configuration from the existing terminal. Both terminals use the same signed build 6254 executable; the Python package is 5.0.6180. Native MQL5 CopyRates/CopyTicksRange ran first, then the official Python SDK read the same intervals. Each API repeated each case three times. All 18 observations reported no query error; M1 series were synchronized after the reads, and the stabilized results matched the existing terminal.

These are RAW numeric query labels, NOT certified UTC instants. End is exclusive; native tick bounds were start*1000 through end*1000-1:

EURUSD: [1623187800, 1623188700): 13 M1 bars, 235 ticks. Minute 1623188580 has 15 changing-Bid ticks and minute 1623188640 has 23, but neither has a returned M1 bar. Minute 1623188520 also has a different closing Bid.

XAGUSD: [1767397500, 1767398400): 12 M1 bars, 510 ticks. All 12 common minutes have different Bid OHLC. In each minute, at least one native OHLC price does not occur in that minute's returned Bid ticks, so selecting a subset of those ticks cannot reproduce that native bar. First native open: 72.613; first returned tick Bid: 72.650.

XAUUSD: [1735861500, 1735862400): 14 M1 bars, zero returned ticks. This is an observation for that exact interval, not a claim of market closure or the absence of all gold tick history.

Current SYMBOL_CHART_MODE is Bid for all three; we do not assume that proves the historical chart basis. We also do not equate COPY_TICKS_ALL row counts with native tick_volume.

For these exact cases, can the history team clarify whether the native bar and tick archives use different sources, historical chart bases, revisions/backfills or time-label mappings? What supported procedure obtains mutually consistent history? Separately, is there a retained effective offset/DST schedule, or a responsible data-feed authority, for converting this server's older raw labels to UTC? If that history cannot be certified, an explicit statement of the limitation would also help us choose an honest validation scope.

We are preserving the raw observations and withholding historical qualification rather than shifting timestamps or reconstructing replacement bars by assumption. Thank you.

[gametiny]

After further reading, I found Aytugan Khafizov's 9 November 2016 statement describing MetaQuotes-Demo as EET (GMT+2) with daylight saving time:

https://www.mql5.com/en/forum/399066/page5

MetaQuotes' 2016 company news identifies him as its CIO:

https://www.metaquotes.net/en/company/news/4720

Could the history team confirm how that policy applies to the retained 2021–2026 labels: which exact DST transition calendar is used, and whether there are symbol-specific exceptions or retrospective relabelling? The dated statement is helpful, but we are not treating it alone as certification of every historical interval.