MetaQuotes-Demo XAUUSD: historical Python timestamp-to-UTC mapping and DST schedule (14–16 October 2026)

New comment

Hello MetaQuotes team and MQL5 community,

I am investigating timestamp alignment for read-only XAUUSD historical research on MetaQuotes-Demo. Could the team responsible for this server confirm the historical mapping of returned Python timestamps to actual UTC, especially 14–16 October 2026?

Environment
- Windows, local timezone South Africa Standard Time (UTC+2; no active DST).
- MetaTrader 5 build 6272, terminal version date 16 October 2026.
- Official MetaTrader5 Python package 5.0.6231; Python 3.12.14, 64-bit.
- Server: MetaQuotes-Demo. Symbol: XAUUSD, Metals/XAUUSD, custom=false.
- Historical timeframes: D1, H4, H1, M15 and M5.

What we checked
- The same raw timestamp values are returned by a standalone SDK probe under isolated Python (-I), before any application, pandas, API or chart conversion.
- Default and explicit terminal-path initialization select the same terminal/server. Only one MT5 terminal was found running.
- Installed SDK Python and compiled binary files match the published CPython 3.12 Windows wheel byte-for-byte.
- No relevant timestamp environment overrides were found.
- Production history queries use timezone-aware datetimes. Integer epoch bounds, aware UTC bounds and equivalent aware UTC+2 bounds return the same H1 candle. Naive UTC-looking datetime fields select a candle two hours earlier on this PC; production does not use that form.
- The application preserves the SDK raw value, applies its previously measured 10,800-second correction once, and converts the resulting instant to Africa/Johannesburg for display. No double subtraction or seconds/milliseconds mix-up was found. This measured correction is not being treated as a historical certificate.
- On 17 October, Windows UTC agreed with independent UTC references within seconds. Windows Time synchronization was stopped, so this is only a point comparison, not a long-term synchronization guarantee.

Historical observations
These are MT5 chart labels, NOT verified UTC timestamps. The chart observations matched the retrieved OHLC values:

Timeframe | MT5 label | Open | High | Low | Close
D1 | 2026-10-15 | 4106.46 | 4176.40 | 4099.74 | 4175.63
H1 | 2026-10-15 22:00 | 4157.83 | 4176.40 | 4157.75 | 4175.63
H1 | 2026-10-16 01:00 | 4166.16 | 4172.56 | 4126.31 | 4164.45

The first D1 row has raw Python time 1792022400. The 15 October 22:00 H1 row has raw time 1792101600. Decoding those integers as UTC reproduces the chart wall-clock labels; this does not establish that the labels represent actual UTC instants.

A cross-timeframe audit found 283/283 available daily OHLC matches against each of H4, H1, M15 and M5. For the daily bar labelled 15 October, lower-timeframe history contains 22 H1 bars (01:00 through 22:00), 88 M15 bars and 264 M5 bars. The nominal 00:00 and 23:00 hourly slots are absent. We have not filled these gaps or assumed their cause.

Earlier M5 comparisons supported a UTC+3 hypothesis for 14–15 October. Matching OHLC values alone do not prove that offset or establish its validity throughout either day.

Weekend limitation
The isolated probe ran on Saturday 17 October. Its final tick was frozen: time=1792191599 and time_msc=1792191599965. The application correctly marked it stale. The difference between this frozen tick and Saturday's clock is NOT a current offset measurement. A fresh paired native-MQL5/Python capture has not yet been performed, so we cannot exclude every possible terminal/SDK implementation issue.

Documentation context
The Python copy_rates_range reference describes UTC timestamps:
https://www.mql5.com/en/docs/python_metatrader5/mt5copyratesrange_py
A moderator clarification describes returned values as broker-server time and notes a documentation issue:
https://www.mql5.com/en/forum/516958
We need server-specific historical confirmation rather than extrapolating a general explanation.

Additional historical source: EET/EEST hypothesis
A direct statement by Aytugan Khafizov appears in reply #24, dated 2 November 2016 at 08:23, on page 3 of the MOEX demo discussion:
https://www.mql5.com/en/forum/399066/page3
It describes MetaQuotes-Demo as using EET (GMT+2 with daylight saving time). This corrects our earlier attribution to 9 November 2016. The separately supplied page 5 could not be retrieved during our review, so any distinct statement there remains unchecked:
https://www.mql5.com/en/forum/399066/page5

What this establishes
- A contemporary first-party statement described the server's EET-with-DST convention in November 2016, in a MOEX discussion.
- The published European summer-time schedule for 2026 runs from 29 March at 01:00 UTC to 25 October at 01:00 UTC:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52021XC0427%2801%29
- Our chart observations match the retrieved prices, and our isolated SDK tests establish the raw numeric values before application conversion.

What remains a hypothesis
If that server convention continued unchanged and the Python fields preserve server-clock labels, 14-16 October 2026 would use EEST (UTC+3). Under that conditional interpretation:
MT5 label | Proposed UTC | Proposed SAST
D1 15 October 00:00 | 14 October 21:00 | 14 October 23:00
H1 15 October 22:00 | 15 October 19:00 | 15 October 21:00
H1 16 October 01:00 | 15 October 22:00 | 16 October 00:00
The D1 value is a proposed nominal bucket boundary, not evidence that a quote existed at midnight.

This model is consistent with the earlier M5 comparisons and the saved 16 October current-tick observation supporting +180 minutes at that observation. The raw audit contains 264 M5 and 22 H1 bars on each of 14 and 15 October. Price aggregation is unchanged by a shared offset and cannot independently prove UTC+3. The absent hourly slots remain absent. The audit snapshot for 16 October was captured before that trading day finished and must not be treated as complete-day coverage.

The 2016 statement does not establish uninterrupted application through 2026, exact transition instants for this server, the Python numeric encoding, or XAUUSD maintenance sessions. The European calendar is independently sourced; its application to this server is not independently confirmed. No additional historical interval has been marked verified.

Questions
1. On MetaQuotes-Demo, do Python rate.time, tick.time and tick.time_msc encode actual UTC instants or broker-server wall-clock labels? Does the Python bridge apply any conversion for this terminal/package combination?
2. What exact mapping applies to XAUUSD on 14, 15 and 16 October 2026? Please distinguish terminal display time from the returned Python numeric timestamps.
3. Does the EET-with-DST convention described on 2 November 2016 still apply to the October 2026 XAUUSD history and raw Python timestamp fields? What historical offset/DST rule does this server use? Please provide exact UTC effective instants for seasonal transitions, the applicable date range and any historical changes or exceptions. An authoritative table or reference would be ideal.
4. How are D1 and H4 opening/closing boundaries defined, including around DST transitions? How are repeated or skipped server-clock labels represented?
5. Are the absent 00:00 and 23:00 H1 slots on 15 October expected trading-session/maintenance gaps? Where is the authoritative XAUUSD session and holiday schedule for these dates?
6. If a native MQL5/Python paired capture is necessary, which native fields and server-clock references should be captured to establish the UTC mapping conclusively?

Historical automatic analysis remains restricted wherever the UTC mapping is unverified. This is market-data research only; no orders are submitted.

Thank you.

Documentation on MQL5: copy_rates_range / Python Integration
Documentation on MQL5: copy_rates_range / Python Integration
  • www.mql5.com
Get bars in the specified date range from the MetaTrader 5 terminal. Parameters symbol [in]  Financial instrument name, for example, ...
For question 6, I would capture fresh XAUUSD quotes outside the Strategy Tester, keeping the raw numbers before applying any UTC correction.

On the MQL5 side: SymbolInfoTick time, time_msc, bid, ask and flags; TimeCurrent(), TimeTradeServer() and TimeGMT(); plus terminal build, account server and exact symbol name. On the Python side: the same tick fields and UTC-aware wall-clock timestamps immediately before and after symbol_info_tick(). Compare repeated captures of the same quote, using time_msc and prices, rather than subtracting the time of a stale Saturday tick from the current clock.

There are two traps in the clock references. TimeCurrent() is the last quote time, not an independent UTC clock. TimeTradeServer() is calculated by the terminal and depends on the computer time settings: https://www.mql5.com/en/docs/dateandtime/timetradeserver

TimeGMT() also depends on the local computer clock. In the Strategy Tester it equals the simulated TimeTradeServer(), so that comparison cannot recover a historical UTC offset: https://www.mql5.com/en/docs/dateandtime/timegmt

This gives you a check of current native-versus-Python output. It cannot certify the mapping or DST schedule for 14-16 October. That still needs server-specific historical information or paired UTC captures from those dates. I would keep those historical intervals unclassified until that evidence exists.

Documentation on MQL5: TimeTradeServer / Date and Time
Documentation on MQL5: TimeTradeServer / Date and Time
  • www.mql5.com
Returns the calculated current time of the trade server. Unlike TimeCurrent() , the calculation of the time value is performed in the client...

Thank you for this detailed investigation.

I am working on a read-only XAUUSD historical data analysis project using MetaQuotes-Demo, covering October 2023 through October 2026.

We are facing similar timestamp and historical session-validation issues.

Could MetaQuotes please confirm:

  1. Whether the historical EET/EEST timezone policy applies to XAUUSD throughout 2023–2026, including exact DST transition rules.

  2. The official historical XAUUSD quote sessions, daily maintenance breaks, holidays and weekend closures.

  3. Whether any historical data gaps or feed interruptions are documented.

  4. The price basis and daily candle boundaries for XAUUSD, particularly on January 30 and February 2, 2026.

A dated official document or confirmation from the MetaQuotes-Demo history team would be greatly appreciated.

We are preserving the original data and have not enabled automated trading or model training.

Thank you.

New comment