MetaQuotes-Demo build 6182: Python timestamps appear 3 hours ahead of UTC

[Jason Farrugia]

Hello,

Could someone clarify the numeric timestamp semantics returned by the official MetaTrader5 Python package on MetaQuotes-Demo, terminal build 6182?

During a read-only export on 10 September 2026 at approximately 06:47:27 UTC (16:47 AEST), we recorded:

• AUDJPY symbol_info_tick:

  time = 1789033638

  time_msc = 1789033638098

Interpreted as Unix UTC, these represent 09:47:18.098—approximately three hours ahead of capture time.

• All 16 symbols showed internally consistent time/time_msc pairs, with tick timestamps 10,787–10,791 seconds ahead of capture UTC.

• copy_rates_from_pos(..., 0, count) returned mixed freshness. EURUSD, GBPUSD and USDJPY had a final M5 timestamp of 1789033500 (09:45 UTC), while other symbols ended on September 8 or August 28.

• No datetime argument was used for these tick/bar requests. Numeric timestamps were preserved without adding or subtracting an offset.

• Historical deals/orders were requested using UTC-aware bounds. Ten matched historical close claims differed by exactly three hours from previously retained UTC-labelled records; three other claims matched without an offset. The correctness of those earlier labels remains under investigation.

• Retained Windows synchronization logs indicate a successful synchronization shortly before capture, with a millisecond-scale offset. This supports the local capture clock but is not independent proof of exact UTC at capture.

• Terminal connections dropped and recovered near capture.

The Python documentation describes tick and bar times as UTC:

https://www.mql5.com/en/docs/python_metatrader5/mt5copyratesfrom_py

Questions:

1. Is there known server/build-specific behavior that encodes server-wall-clock time in these Python fields? If so, is there an official explanation of affected fields, dates and conversion rules?

2. Do timestamp conventions differ between tick/bar data and historical deals/orders? How can we verify the actual UTC of an affected record without assuming a universal three-hour correction?

3. Can copy_rates_from_pos return stale cached history immediately after reconnect while terminal.connected is true? What supported read-only checks establish history synchronization and completeness?

The Python package version was not recorded during capture, so I cannot reliably supply the version used for that export.

No timestamp correction has been applied. No account identifiers or private logs are attached.

Could MetaQuotes confirm the expected behavior or suggest a minimal diagnostic to distinguish timestamp encoding from stale cached data?

Thank you.

[Ryan L Johnson]

Jason Farrugia:
Is there known server/build-specific behavior that encodes server-wall-clock time in these Python fields? If so, is there an official explanation of affected fields, dates and conversion rules?

See Time zone Information Class (tzinfo) at:

Articles

Implementing Practical Modules from Other Languages in MQL5 (Part 04): time, date, and datetime modules from Python

Omega J Msigwa, 2025.11.25 11:58

Unlike MQL5, Python programming language offers control and flexibility when it comes to dealing with and manipulating time. In this article, we will implement similar modules for better handling of dates and time in MQL5 as in Python.

[Jason Farrugia]

I found two earlier discussions reporting similar Python timestamp discrepancies:

https://www.mql5.com/en/forum/375461
https://www.mql5.com/en/forum/483468

The replies suggest broker-time encoding despite the Python documentation stating UTC.

Could MetaQuotes confirm whether this applies to MetaQuotes-Demo build 6182, and which tick, bar and historical deal/order fields are affected?

We also have stale bars on some symbols, so a timezone adjustment alone would not resolve the full issue. No correction has been applied.

[Jason Farrugia]

I also found a similar report on Stack Overflow, including a comment reporting UTC requests returning UTC+3:

https://stackoverflow.com/questions/79595025/timezones-and-offsets-handling-when-fetching-metatrader5-data-via-mt5-api

Could MetaQuotes clarify whether the same behavior applies to MetaQuotes-Demo build 6182 and how to establish the correct UTC interpretation for our retained records?

[Ryan L Johnson]

Jason Farrugia #:
Could MetaQuotes clarify whether the same behavior applies to MetaQuotes-Demo build 6182...

I'm in the ET time zone (NY) which observes DST. The Metaquotes Demo server time has always returned 7 hours ahead of my local time. Therefore, the Metaquotes Demo server time observes DST. In my time zone conversions, all times relate back to GMT as a "constant" point of reference, if you will.

The trade server determines the time zone of the chart data─not any Build of MT5.

[Jason Farrugia]

Thank you, Ryan. A separate read-only observation has now identified historical-data changes as well as the timestamp question.

Environment: MetaQuotes-Demo, terminal build 6182, MetaTrader5 Python package 5.0.5640. This package version was recorded for the new observation only.

On 10 September 2026, three planned calls to copy_rates_from_pos('EURJPY', TIMEFRAME_M30, 0, 240) returned:

• At 20:07:09.760644 UTC: latest raw bar-open label 1789034400.

• At 20:07:40.287144 UTC: latest raw bar-open label 1789081200.

• At 20:08:10.758726 UTC: latest raw bar-open label remained 1789081200.

Two overlapping historical bar labels also changed between the first and second responses:

Raw bar-open 1788829200:

• Close: 179.423 → 179.242

• High: 179.434 → 179.440

• Low: 179.375 → 179.232

• Tick volume: 160 → 2054

Raw bar-open 1789034400:

• Close: 178.620 → 178.559

• High: 178.701 → 178.709

• Low: 178.572 → 178.532

• Tick volume: 2054 → 5752

We identified a client-side serialization/type-handling defect affecting price validation. The prices above were recovered from retained numeric representations during offline analysis. Raw timestamp and volume integers were unchanged. No timezone correction was applied.

We are not claiming a server defect. A stale or partial terminal cache becoming synchronized is one possible explanation. However, a timezone offset alone cannot explain changed prices and volumes at identical raw bar labels.

Could MetaQuotes or someone familiar with the terminal’s history synchronization clarify:

1. Can these changes result from a previously partial or stale local history cache being refreshed?

2. What documented read-only check establishes that the requested history is synchronized and sufficiently complete for use?

3. Are there existing history/version or synchronization records that could distinguish cache completion from a published historical correction?

4. What time convention applies to the raw Python bar timestamps for this server?

The separate newest-bar update may be forming-bar activity; the question above concerns the two historical labels and the changing window.

No account identifiers, credentials or private logs are attached. We would appreciate guidance based on these retained observations before considering any further collection.

Thank you.

[Ryan L Johnson]

Jason Farrugia #:
Can these changes result from a previously partial or stale local history cache being refreshed?

Historic chart data can and does update sometimes. That is demonstrable by mistakenly using Bars() in lieu of rates_total in MQL5 indicator code.

Jason Farrugia #:
What documented read-only check establishes that the requested history is synchronized and sufficiently complete for use?

For checking history of ticks against bars, I use:

Code Base

Tick Audit - check real tick history and backtest quality month by month

Ayaz, 2026.09.05 06:13

Reports, month by month, whether your symbol really has ticks or only bars - so you know which part of your backtest ran on generated ticks before you trust the curve. The Strategy Tester gives you one History Quality figure after the test has finished, and it never says which months were the problem. This script asks first.

For live data, there's RefreshRates():