MetaQuotes-Demo tick timestamps: UTC or server time? Builds 6238 and 6241

New comment
 
Hello,

I need clarification of tick timestamp semantics on MetaQuotes-Demo.

ENVIRONMENT
- Server: MetaQuotes-Demo
- MT5 build during paired capture: 6238
- MetaTrader5 Python package: 5.0.6231
- Windows timezone: UTC+2
- Symbol: EURUSD
- Capture date: 5 October 2026

A later inspection on 6 October reported terminal build 6241. We have not repeated the paired capture on that build, so we cannot say whether its behaviour differs.

DOCUMENTATION
The Python copy_ticks_range documentation describes tick and bar timestamps as UTC without a shift:

Does this also apply to Python symbol_info_tick().time/time_msc and native MQL5 SymbolInfoTick()?

OBSERVATIONS
We collected 120 native MQL5 samples alongside 476 Python polls. Thirty nearest paired snapshots matched raw tick milliseconds and bid/ask exactly. Pairing was approximate, not simultaneous.

Two matching examples:

Example A
- Python UTC observation: 14:23:03.639290–14:23:03.640266
- Native TimeGMT: 1791210183
- Native/Python tick time: 1791220983
- Native/Python tick time_msc: 1791220983280
- Bid/ask: 1.11886 / 1.11886
- TimeCurrent: 1791220983
- TimeTradeServer: 1791220983
- TimeLocal: 1791217383

Example B
- Python UTC observation: 14:25:01.709968–14:25:01.711785
- Native TimeGMT: 1791210301
- Native/Python tick time: 1791221101
- Native/Python tick time_msc: 1791221101060
- Bid/ask: 1.11882 / 1.11883
- TimeCurrent: 1791221101
- TimeTradeServer: 1791221101
- TimeLocal: 1791217501

Across the native samples:
- TimeTradeServer minus TimeGMT: 10,800 seconds.
- TimeLocal minus TimeGMT: 7,200 seconds.

LIMITATIONS
Independent UTC readings agreed with PC UTC before and after capture within integer-second precision. Continuous/subsecond clock synchronisation remains unverified: Windows Time was previously stopped and an NTP query timed out.

TimeGMT is PC-derived; TimeTradeServer is client-calculated. Polling does not establish tick arrival time or executable freshness. Equal bid/ask is recorded as observed, not interpreted as zero trading costs.

The matching native/Python values suggest this is not solely a Python datetime-formatting issue. Server-local timestamp encoding remains a hypothesis, not a confirmed explanation.

QUESTIONS
1. Are these returned tick fields UTC Unix timestamps, server-local calendar timestamps, or evidence of a defect?
2. Is there a documented conversion to UTC for this server, and does the same convention apply to historical bars?
3. If server-local time is used, where are historical UTC offsets and daylight-saving transition rules documented?
4. Is there any relevant timestamp change or fix between builds 6238 and 6241?

No orders were placed during this diagnostic, and no timestamp offset has been applied.

Thank you.
 
Sergey Golubev #:

I am not fully sure that it is related to your question/issue but, anyway - look at the following:


Thank you, Sergey. I read the linked discussions, including Alain’s explanation distinguishing UTC-aware request parameters from broker-server-time outputs. I am not requesting another ticket.

Which explanation applies to this MetaQuotes-Demo EURUSD example from 5 October 2026, terminal build 6238, Python package 5.0.6231?

  • Python UTC observation: 14:23:03.639290–14:23:03.640266.
  • Native TimeGMT: 1791210183; TimeLocal: 1791217383.
  • Identical native/Python tick time: 1791220983; time_msc: 1791220983280; bid/ask: 1.11886/1.11886.
  • Native TimeCurrent and TimeTradeServer: both 1791220983.

Both APIs returned identical raw fields approximately three hours ahead when decoded as UTC, so this is not solely Python display conversion. Pairing was approximate; independent UTC brackets agreed to integer-second precision, not verified subsecond synchronization or arrival latency.

Does server-time encoding apply to these native tick fields too? If so, which MetaQuotes-Demo offset/DST rule and effective dates apply, including transition ambiguities? Otherwise, which recorded field or conversion is wrong?

Build 6241 was observed separately; no paired capture was made on that build. No offset has been applied. A server-specific reference or responsible contact would help.

 

Forum on trading, automated trading systems and testing trading strategies

Authoritative MetaQuotes-Demo tick timestamp and copy_ticks_range time-domain semantics

Alain Verleyen, 2026.09.24 17:35

I reported the documentation issue about datetime and timezone to MetaQuotes. 

So you get different data because you request different datetime, python/MQL5 API request UTC datetime. But the data MT5 returns are ALWAYS broker server time data.

That seems pretty clear to me.

Detecting the server time offset is your job.

Please note MetaQuotes is NOT a broker and so MetaQuotes-Demo server should not be used for something else than technical tests.

New comment