MT5 Python API Timestamp Discrepancy on MetaQuotes-Demo — Build 6259

New comment
# Support request: MT5 Python timestamps on MetaQuotes-Demo

**Subject:** Please confirm timestamp semantics/server-time basis for MT5 Python API on MetaQuotes-Demo (terminal build 6259)

Hello MetaQuotes Support,

Please confirm the timestamp basis for the following read-only MetaQuotes-Demo capture (14 October 2026). The connected Windows terminal reported build **6259**; `mt5.version()` returned `(500, 6259, "12 Oct 2026")`; the installed MetaTrader5 Python package was **5.0.6231**. The terminal reported itself connected to `MetaQuotes-Demo`.

At PC UTC `2026-10-14 06:48:56.304Z`, a repeated `symbol_info_tick()` capture returned `tick.time` and `tick.time_msc` which, when converted as Unix epoch seconds/milliseconds to UTC, were **10,797.094–10,800.022 seconds ahead** for all seven configured symbols: AUDUSD, EURJPY, EURUSD, GBPJPY, GBPUSD, USDJPY and XAUUSD. The latest available and latest closed M1 bars returned by `copy_rates_from_pos()` were also about three hours ahead of PC UTC. A previous capture at `06:22:22.527Z` showed essentially the same discrepancy; all symbols' M1 timestamps advanced by 26 minutes between captures as PC time advanced by 26 minutes.

To check the PC clock, the user supplied a later elevated Windows Time status: leap indicator 0, stratum 5, last successful sync `11:40:25 AM` local (`06:40:25Z` at UTC+05:00), source `time.windows.com,0x8`, phase offset `+0.0001591s`, last sync error 0, and 344.7205037 seconds since last good sync. An independent platform UTC clock also bracketed the repeated PC capture within seconds. These results make a three-hour PC clock error unlikely at the repeat capture. Redacted raw MT5 values are attached in `mt5-independent-diagnostic-20261014T064856582654Z.json`, the pairwise comparison is in `mt5-independent-comparison-20261014.json`, and the user-provided Windows status is preserved in `mt5-w32tm-elevated-status-user-provided-20261014.json`. Account identifiers, credentials and prices are omitted.

MetaQuotes' Python documentation states that terminal-returned tick and bar data are UTC. Could you please clarify for this specific MetaQuotes-Demo environment:

1. Are `tick.time`, `tick.time_msc`, and rates `time` guaranteed to be Unix UTC epochs in this terminal/package build?
2. Does this server intentionally encode broker/server wall time in those epoch fields? If so, what is its authoritative timezone and historical/DST rule?
3. Is there an authoritative current server-time field or API available through the Python integration? The installed module exposed no apparent server-clock method, and `terminal_info()` had no server/time field.
4. Is this a known terminal/server/API issue, and what additional redacted logs or reproduction steps would help verify it?

We have not applied an offset or treated these quotes as valid. No order was placed. We did not compare a chart display because its timezone/display semantics were not established. Please provide the supported timestamp semantics and a reproducible way to validate them against server time.

Regards,
Sahir user

It was already discussed many times, for example:
Can MQL5 uniquely determine the UTC open time of historical CopyRates bars?
Can MQL5 uniquely determine the UTC open time of historical CopyRates bars?
Can MQL5 uniquely determine the UTC open time of historical CopyRates bars?
  • 2026.10.09
  • www.mql5.com
Subject: Can MQL5 uniquely determine the UTC open time of historical CopyRates bars...
Sergey Golubev #:
It was already discussed many times, for example:
Can MQL5 uniquely determine the UTC open time of historical CopyRates bars?
Thank you for the reference. For my specific MetaQuotes-Demo environment (terminal build 6259, Python package 5.0.6231), could you please clarify:

1. Is the approximately UTC+3 timestamp difference expected for MetaQuotes-Demo?
2. What authoritative source confirms the current offset and any DST changes?
3. Does the same interpretation apply to both "symbol_info_tick()" timestamps and "copy_rates_from_pos()" bar timestamps?

I will not apply a fixed offset until the timestamp mapping is verified. All quotes remain unverified for trading purposes.

Thank you.

Hello MetaQuotes technical team,

I am following up on the timestamp discrepancies reported in this thread. I am auditing read-only EURUSD H1 historical data from MetaQuotes-Demo and need clarification about the original timestamps before attempting any UTC conversion.

Could a MetaQuotes engineer or someone familiar with the historical configuration of MetaQuotes-Demo clarify the following?

1. MT5 API timestamp semantics

Do MQL5 MqlRates.time and Python rates time represent actual POSIX UTC bar-opening instants, or can they encode server-local clock labels as epoch-shaped integers?

Does this differ between MQL5 and Python or between current and historical bars?

Separately, what do tick time and time_msc represent? Are tick timestamps governed by the same clock rules as historical H1 bars?

Which clock domain is used for datetime bounds in Python copy_rates_range and copy_ticks_range, and are the endpoints inclusive?

2. MetaQuotes-Demo historical server configuration

For EURUSD between 12 October 2024 and 12 October 2026, could you confirm the server's historical UTC offsets and their exact effective intervals?

Were there daylight-saving changes, exceptions, server migrations, or retrospective history rebuilds?

How should the first H1 bars after market reopenings around 27 October 2024, 30 March 2025, 26 October 2025, and 29 March 2026 be interpreted?

3. Observed discrepancies

In a controlled October 2026 comparison, MQL5 CopyRates and Python copy_rates_from_pos returned identical raw time integers for 15 matched bars.

At 2026-10-21 23:36 UTC, the chart labelled its current H1 bar 2026-10-22 02:00, with raw integer 1792634400. A literal POSIX UTC interpretation would place the bar opening after the observation.

Independent BID H1 OHLC comparisons with Dukascopy UTC data were compatible, on observed bars only, with candidate shifts of UTC+3 before / UTC+2 after the October 2024 and 2025 transitions, and UTC+2 before / UTC+3 after the March 2025 and 2026 transitions.

These are observations and hypotheses, not confirmed MetaQuotes-Demo server rules.

4. Official UTC reconstruction

If historical bar timestamps encode server-local clock labels, is there an officially supported and unambiguous method to recover their original UTC instants, including DST transitions and market reopenings?

Could you provide a dated technical reference, historical server-configuration record, or authoritative contact who can confirm these rules for bars and ticks separately?

If the historical configuration cannot be verified, please state that limitation explicitly.

No account access or private credentials are required.

Thank you for your assistance.

New comment