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

# 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.