MetaTrader 5 timestamp semantics: MQL5 native and Python API return identical broker-server-aligned timestamps

New comment
 

Hello MetaQuotes Support,

I am requesting clarification on the timestamp semantics of MetaTrader 5 market data.

Environment:

  • MetaTrader 5 terminal build: 6231
  • Python MetaTrader5 package: 5.0.6231
  • Symbol: XAUUSD
  • Broker server: PhyntexGroupLimited-Live
  • Windows system timezone: UTC+8

I performed a controlled read-only comparison between native MQL5 and the official MetaTrader5 Python API.

The native MQL5 script captured:

  • SymbolInfoTick() / MqlTick.time
  • MqlTick.time_msc
  • CopyTicks()
  • CopyRates()
  • TimeCurrent()
  • TimeTradeServer()
  • TimeGMT()
  • TimeLocal()
  • TimeGMTOffset()

The Python collector independently captured:

  • symbol_info_tick()
  • copy_ticks_from()
  • copy_rates_from_pos()

For the overlapping CopyTicks data, 256 out of 256 ticks matched exactly between native MQL5 and Python, including:

  • time
  • time_msc
  • bid
  • ask
  • flags
  • ordering

However, the raw tick timestamps were approximately 10,799 seconds (~3 hours) ahead of contemporaneous PC UTC/GMT.

Native MQL5 TimeCurrent() also aligned with the latest raw market tick timestamp to within approximately 0–1 second.

Therefore, the approximately +3 hour displacement already exists in the raw timestamps returned by the terminal/native MQL5 interface; it is not introduced by Python datetime conversion.

Could you please clarify the official contract for these timestamp fields?

  1. Is MqlTick.time / time_msc returned by SymbolInfoTick() and CopyTicks() guaranteed to represent Unix epoch UTC, independent of the broker's MetaTrader server timezone?

  2. Does the official MetaTrader5 Python API preserve exactly the timestamp values supplied by the terminal, or does the Python bridge perform any timezone normalization?

  3. Are timestamps returned by copy_rates_from_pos() / native CopyRates() defined in UTC, broker server time, or another time basis?

  4. Can a broker's server timezone (for example GMT+2/GMT+3) legitimately affect the raw epoch values returned for ticks or bars?

  5. If raw native MQL5 and Python timestamps are identical but align with TimeCurrent() / broker server time rather than UTC, should an application treat this as expected MetaTrader behavior, broker-specific behavior, or an invalid/non-conforming feed?

I specifically need to know whether applications should ever normalize such timestamps using the broker's documented server UTC offset, or whether the raw values must always be treated as UTC and a non-UTC result should instead be rejected.

No trading operation was involved in this test. It was entirely read-only.

Thank you.

 

Yes, that's expected. Tick and bar times in MT5 (MqlTick.time, time_msc, CopyRates, CopyTicks) are in the broker's trade server time, not UTC, and the Python package just passes the same values through. Your ~3h gap is simply that server's GMT offset. If you need UTC, get the offset live and subtract it:

int offset = (int)(TimeTradeServer() - TimeGMT());   // seconds

Just keep in mind that in the Strategy Tester TimeGMT() equals the simulated server time, so this gives 0 there.

New comment