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

[DeepQuant]

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.

[DeepQuant]

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.

[DeepQuant]

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.

[shaheer qamar]

Subject: MetaQuotes-Demo EURUSD/GBPUSD M1/M5 timestamp conversion for Aug–Oct 2026

Please confirm the authoritative source-time-to-UTC conversion for the following MetaQuotes-Demo historical bar labels, downloaded using terminal build 6254:

- EURUSD and GBPUSD M1: 2026-10-06 12:18 through 2026-10-16 20:18.

- EURUSD and GBPUSD M5: 2026-08-20 04:15 through 2026-10-16 20:10.

These are original encoded source labels, not asserted UTC instants. At capture on 16 October, raw tick values were approximately three hours ahead of an independently cross-checked host UTC clock. Raw epochs have been preserved.

We found the 9 November 2016 statement describing MetaQuotes-Demo as EET with daylight-saving time. Please confirm its applicability to this bounded download:

1. Do the returned bar epochs encode server wall-clock labels or actual UTC?

2. What offset and exact effective interval apply to each covered symbol/frame?

3. What is the conversion formula, and what clock domain do range queries use?

4. Can history be relabelled retrospectively, or are there source migrations, symbol-specific exceptions or other changes affecting these intervals?

A dated policy statement with covered symbols and exact validity bounds would allow us to retain the raw data and create a separate, auditable UTC dataset. If the mapping cannot be guaranteed, please state that limitation explicitly.

[DeepQuant]

Bounded EURUSD follow-up: effective quote clock and three native history gaps

Could this be routed to the team responsible for MetaQuotes-Demo quote/history storage? We have narrowed qualification to EURUSD. A statement for every instrument since 2021 is not needed for this candidate.

Effective clock: for the retained EURUSD raw-label selection [1760572800,1792022400) (numeric labels rendering as 16 October 2025 to 15 October 2026), please clarify the time domains of MqlRates.time, MqlTick.time/time_msc and range-query bounds. What raw-to-UTC rule, effective DST intervals, exceptions and history relabelling/backfill policy apply? The Python documentation describes UTC, while our retained contemporaneous observation has raw tick time approximately three hours ahead of independently checked host UTC. Native and Python reads agree on returned numbers. We are asking about this source's effective semantics, not assuming a DST calendar.

Three exact half-open RAW intervals (not asserted UTC) have no returned M1 or ticks:

A: [1780572720,1780572840) - 4 June 2026, 11:32-11:34, 2 minutes.

B: [1784908800,1784908920) - 24 July 2026, 16:00-16:02, 2 minutes.

C: [1790264700,1790264940) - 24 September 2026, 15:45-15:49, 4 minutes.

Main terminal build 6271 and portable terminal build 6264 reproduce these gaps without a reported query error. Surrounding one-minute halos contain 69/183/401 ticks, and all nine containing M15/H1/H4 bars agree. We do not claim a same-build experiment. Our frozen M1 snapshot has the first raw-label gap in 29/30 symbols and the other two in 30/30; this is not proof of a feed-wide outage or identical UTC clocks.

For A, B and C separately, could the responsible team identify:

1. No quotes originally published, history lost/omitted, cache/API delivery issue, clock/source revision, or cause not retained/unknown?

2. Affected feed/account group/symbol and applicable clock/bounds?

3. If dissemination stopped, did server pricing or stop execution continue on an internal stream?

4. If history was corrected, which supported procedure/revision retrieves the original native Bid/Ask ticks and consistent bars?

If records or historical clock policy cannot be certified, an explicit statement of that limitation would also help. We preserve raw data, have not synthesized replacements, and have not released the candidate or sent forward orders. A source explanation can identify limitations but cannot itself reconstruct lost ticks. Bounded query receipts and diffs are available if useful. Thank you.