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

New comment
 
Hello MetaQuotes team,

I need an authoritative, source/runtime-specific clarification for private, non-commercial scientific validation in the forksAi-personal project.

Exact environment:

Server=MetaQuotes-Demo
Company=MetaQuotes Ltd.
Symbol=EURUSD
Terminal build=6204
MetaTrader5 Python package=5.0.5735
APIs=symbol_info_tick() and copy_ticks_range()

For this exact environment, please provide authoritative evidence—such as versioned documentation, an engineering statement, or identification of the responsible technical authority—covering all of the following:

1. The represented event for the returned tick time/time_msc: for example, event creation at the source, receipt by a MetaQuotes server, server ingestion, terminal receipt, or another precisely defined event.

2. The exact time domain, epoch, timezone, and units of the returned time and time_msc fields.

3. The exact time domain expected for the datetime request bounds supplied to copy_ticks_range(), including how those bounds are interpreted and converted before the query is executed.

4. The complete source-time-to-UTC mapping rule and its validity periods, including epochs, DST policy, server-time changes, and any historical regime changes.

5. A quantitative worst-case total timing-error bound from the represented event to canonical UTC. The complete bound must include all applicable components, such as clock synchronization, timestamp assignment, transport or buffering, and API precision or quantization. For our validation requirement, the proven worst-case total error must be strictly less than 5000 ms.

6. Whether these semantics, mapping rules, and error bounds remain valid across terminal and Python-package updates, server updates, reconnects and restarts, and both historical and prospective tick retrieval. Please also explain how relevant changes are versioned or communicated.

A general statement such as “timestamps are UTC,” “use UTC,” or “timestamps use broker/server time” is not sufficient unless it explicitly resolves every item above for the stated source/runtime and supplies the complete quantitative uncertainty bound.

If MetaQuotes does not publish or guarantee this information, please state that explicitly and identify the authoritative document, engineering owner, server operator, or support channel that can provide it.

Thank you.
 
Could you please route this existing question to the responsible specification owner or technical authority?

We need an authoritative, source/path-specific answer for the exact MetaQuotes-Demo / MetaQuotes Ltd. / EURUSD / terminal build 6204 / MetaTrader5 Python 5.0.5735 path using symbol_info_tick() and copy_ticks_range(). In particular: the represented event; returned-timestamp and request-bound domains; the source-to-UTC mapping including offset/DST rules and validity epochs; a guaranteed worst-case total absolute timing-error bound and whether it is strictly below 5000 ms; and durability across restarts, updates, historical data, and prospective retrieval.

If this information is not published or guaranteed, an explicit statement to that effect, an official specification link, or the authoritative technical contact would be equally useful. Full details are already in the opening post. Thank you.

 

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

Where is the documentation wrong ? Each time it claims the following :

When creating the 'datetime' object, Python uses the local time zone, while MetaTrader 5 stores tick and bar open time in UTC time zone (without the shift). Therefore, 'datetime' should be created in UTC time for executing functions that use time. Data received from the MetaTrader 5 terminal has UTC time.  

The confusion comes from how Python datetime is working, by default it will use the local timezone, the one of the computer where the python code is running, so to avoid returning different data depending where your code run, it's requested to set UTC timezone for each datetime parameter used in a python/MQL5 functions. So you need to use an UTC timezone datetime to finally receive data using the broker server timezone including DST.

An example to illustrate this :

# set time zone to UTC
timezone = pytz.timezone("Etc/UTC")
# create 'datetime' object in UTC time zone to avoid the implementation of a local time zone offset
utc_from = datetime(2025, 1, 10, 0, 0, tzinfo=timezone)
# get 10 EURUSD H4 bars starting from 01.10.2020 in UTC time zone
rates = mt5.copy_rates_from("EURUSD", mt5.TIMEFRAME_H1, utc_from, 1)

# Check without any UTC reference
dt_from = datetime(2025, 1, 10, 0, 0)
ratesCheck = mt5.copy_rates_from("EURUSD", mt5.TIMEFRAME_H1, dt_from, 1)

 
# shut down connection to the MetaTrader 5 terminal
mt5.shutdown()
# display each element of obtained data in a new line
print("Display obtained 'UTC TZ' data 'as is'")
for rate in rates:
   print(rate)
 
# create DataFrame out of the obtained data
rates_frame = pd.DataFrame(rates)
# convert time in seconds into the datetime format
rates_frame['time']=pd.to_datetime(rates_frame['time'], unit='s')
                           
# display data
print("\nDisplay dataframe with date_from using UTC")
print(rates_frame)  

# display each element of obtained data in a new line
print("Display obtained 'local TZ' data 'as is'")
for rate in rates:
   print(ratesCheck)

# create DataFrame out of the obtained data
rates_frame_check = pd.DataFrame(ratesCheck)
# convert time in seconds into the datetime format
rates_frame_check['time']=pd.to_datetime(rates_frame_check['time'], unit='s')
                           
# display data
print("\nDisplay dataframe with date_from using local time (no TZ specified)")
print(rates_frame_check)  

2026.09.24 13:27:39.878    Display obtained 'UTC TZ' data 'as is'
2026.09.24 13:27:39.878    (1736467200, 1.03011, 1.03011, 1.0294, 1.02998, 288, 4, 0)
2026.09.24 13:27:39.878    
2026.09.24 13:27:39.878    Display dataframe with date_from using UTC
2026.09.24 13:27:39.878            time     open     high     low    close  tick_volume  spread  real_volume
2026.09.24 13:27:39.878    0 2025-01-10  1.03011  1.03011  1.0294  1.02998          288       4            0
2026.09.24 13:27:39.878    Display obtained 'local TZ' data 'as is'
2026.09.24 13:27:39.878    [(1736485200, 1.03016, 1.03031, 1.02975, 1.02983, 698, 0, 0)]
2026.09.24 13:27:39.878    
2026.09.24 13:27:39.878    Display dataframe with date_from using local time (no TZ specified)
2026.09.24 13:27:39.878                     time     open     high      low    close  tick_volume  spread  real_volume
2026.09.24 13:27:39.878    0 2025-01-10 05:00:00  1.03016  1.03031  1.02975  1.02983          698       0            0

2025.10.01 00:00 is 1736467200 (epoch time in seconds) 

2025.10.01 05:00 is 1736485200 with my local timezone shift at that date. If you run this code from a different timezone, the first one will be the same, but the second one will differ.

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.

New comment