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():

[Jason Farrugia]

MetaQuotes-Demo EURJPY: timestamp offset, historical revisions and CopyRates 4401

I’m investigating EURJPY data consistency using native MQL5 and the MetaTrader5 Python package. These were read-only diagnostics; no trading calls were made and no timestamp correction has been applied.

Environment:

• Server: MetaQuotes-Demo

• Terminal build: 6193

• MetaTrader5 Python package: 5.0.5640

• Python: 3.10.10

• Native comparison implemented as an indicator on EURJPY,H1, requesting M5/M30 data.

1. Native and Python tick timestamps approximately three hours ahead of receipt UTC

Two observations from 14 September 2026:

Receipt UTC: 2026-09-14T18:24:41.287754Z
Raw tick time: 1789421081
Raw time_msc: 1789421081103
time_msc/1000 minus receipt UTC: +10799.815246 seconds

Receipt UTC: 2026-09-14T18:25:41.329529Z
Raw tick time: 1789421140
Raw time_msc: 1789421140639
time_msc/1000 minus receipt UTC: +10799.309471 seconds

Native SymbolInfoTick timestamp and price fields matched the corresponding Python ticks in both rounds. The offset therefore appears in both interfaces.

Four retained, unauthenticated SNTP responses from two sources gave local clock-offset intervals of +0.021876 to +0.107302 seconds before collection and +0.026994 to +0.075463 seconds afterward. This supports a small local clock offset during this capture, but is not authenticated clock proof.

The Python documentation describes UTC timestamps:
https://www.mql5.com/en/docs/python_metatrader5/mt5copyratesrange_py

What conventions apply separately to SymbolInfoTick time/time_msc, TimeCurrent, CopyRates bar-open timestamps and their Python equivalents on this server? Is there a documented server/date-specific timezone or DST explanation for these observations?

2. Earlier historical bar values differ from later reads

Fixed EURJPY M30 request windows:
[1788827400, 1788831000]
[1789032600, 1789036200]

Later values for two disputed raw bar-open labels:

1788829200:
Open 179.375, High 179.440, Low 179.232, Close 179.242
Tick volume 2054, Spread 0, Real volume 0

1789034400:
Open 178.584, High 178.709, Low 178.532, Close 178.559
Tick volume 5752, Spread 0, Real volume 0

Earlier retained responses for those same labels had:

1788829200:
High 179.434, Low 179.375, Close 179.423, Tick volume 160

1789034400:
High 178.701, Low 178.572, Close 178.620, Tick volume 2054

In the later diagnostics, Python integer-bound and aware-UTC datetime requests returned byte-identical buffers. Fixed-window results were also unchanged between rounds, and the successful native reads matched those later values.

How can we establish the authoritative values and whether these records were rebuilt, corrected or synchronized? Matching later client reads does not explain the earlier differences.

3. CopyRates returned −1/4401 despite SERIES_SYNCHRONIZED=true

During the native/Python comparison at approximately 18:24:41–18:25:41 UTC on 14 September:

Round 0:

• Native CopyRates calls for the latest two M5 bars, latest two M30 bars and both fixed M30 windows all returned −1/error 4401.

• SERIES_SYNCHRONIZED returned true for M5 and M30 before and after these calls.

• Native bar-count and first/last-bar queries also failed with 4401.

• Python returned history.

Round 1, approximately 60 seconds later:

• All four native history requests succeeded.

• All six comparisons against Python requests matched, including the integer/aware-UTC variants.

I understand that CopyRates called from an indicator can return −1 while initiating history downloading/building:
https://www.mql5.com/en/docs/series/copyrates

The observations are consistent with initial loading, but do not prove that cause. What additional checks should accompany SERIES_SYNCHRONIZED to establish that the requested history is available, sufficiently covered and current? What is the supported equivalent approach for Python?

An earlier Python capture also returned latest M5 labels 1789083300 and then 1789345200 approximately 60 seconds apart—a 261,900-second label jump. Could history loading/cache refresh explain this, and how should stale cached results be distinguished from current history?

We recognise that position-zero bars can change while forming; those changes alone are not being classified as completed-bar corruption.

Redacted raw requests, responses and relevant logs can be provided. I’m looking for documented behaviour and evidence-based checks rather than assuming a fixed three-hour correction.

Thanks in advance

Jason

[Jason Farrugia]

Hello everyone,

Thank you for the earlier suggestions. Could someone from MetaQuotes, or someone able to provide source-specific documentation, please help clarify the timestamp and history behaviour below?

This has been holding up our validation work for several weeks. We would appreciate assistance identifying the correct interpretation rather than applying an assumed three-hour adjustment.

Following our earlier native MQL5/Python comparison, we completed a read-only capture using MetaQuotes-Demo, terminal build 6194, on 15 September 2026. The computer recorded receipt times of approximately 17:48:27–29 UTC.

1. Tick and bar timestamps

For EURJPY, Python returned:

• time = 1789505305

• time_msc = 1789505305574

• Computer-recorded receipt: 2026-09-15T17:48:28.315582+00:00

• Tick timestamp interpreted as UTC: 2026-09-15T20:48:25.574+00:00

• Difference: 10,797.258418 seconds ahead of receipt.

• Latest M5 bar label: 1789505100 — 20:45 when interpreted as UTC.

• Latest M30 bar label: 1789504200 — 20:30 when interpreted as UTC.

All 16 symbols had consistent tick seconds/milliseconds and approximately the same three-hour difference.

For MetaQuotes-Demo on these dates, what time domain applies separately to tick time , tick time_msc , and bar-open timestamps? Could you provide the applicable offset/session/DST rules, or a source-confirmed UTC mapping for the cited event?

No timestamp correction has been applied.

2. History coverage and differing values

The latest history was mixed. For example, GBPJPY M5 ended on 10 September, while its M15 and H1 series had labels on 15 September.

These were copy_rates_from_pos requests with start_pos=0 , without datetime arguments. Current/forming bars were intentionally included. All requests returned the requested counts, but that does not establish current coverage.

For the previously reported EURJPY M30 differences, could you confirm the authoritative history for these numeric timestamp windows?

• [1788827400, 1788831000]

• [1789032600, 1789036200]

The disputed labels were 1788829200 and 1789034400 . Is there a history/version record that could establish whether the differing values resulted from cache completion, a revision, or another mechanism?

3. How to establish history readiness

In our earlier build-6193 comparison, the first native request returned -1 with error 4401 despite synchronized flags. The next native round matched Python.

What supported read-only check establishes that the requested history is actually available and sufficiently current? Could asynchronous history loading explain this behaviour, and what evidence would distinguish that from another cause?

Clock-evidence limitation

The 15 September capture did not include an independent contemporaneous UTC measurement. Therefore, the receipt time above is the computer’s recorded UTC time, not independently certified UTC.

An earlier 14 September comparison included four unauthenticated SNTP measurements showing small computer-clock offsets, but those do not prove the clock’s accuracy during the later capture. The terminal’s GMT+10 startup display establishes only the displayed local timezone.

A privacy-reviewed extract is available containing the exact selected raw fields, all 52 history request/returned windows, and relevant receipts. Account identifiers, fingerprints, private paths and account trading history are excluded. Original evidence remains privately preserved.

We are seeking clarification of the source’s timestamp and history conventions, without assuming a server fault. No new capture, trading or settings change is proposed in this inquiry.

Thank you for your time and assistance.

Kind regards,
Jason