MetaTrader5 Python history_orders_get/history_deals_get — authoritative time semantics

New comment
 

Dear MetaQuotes Technical Support,

We request an authoritative technical clarification of the time semantics used by the official MetaTrader5 Python package. This is a specification question, not account troubleshooting. The requesting environment uses MetaTrader5 Python package 5.0.5735 with MetaTrader 5 terminal build 6140.

Please answer each question separately:

  1. For history_orders_get(date_from, date_to) and history_deals_get(date_from, date_to), when date_from and date_to are supplied as integer seconds since 1970-01-01, what timezone or time reference do those integers represent: UTC, trading-server time, local terminal or operating-system time, or another convention?
  2. For returned historical order fields ORDER_TIME_SETUP and ORDER_TIME_DONE, and historical deal field DEAL_TIME, what timezone or time reference do the integer or datetime values represent?
  3. For ORDER_TIME_SETUP_MSC, ORDER_TIME_DONE_MSC and DEAL_TIME_MSC, are the millisecond values based on the same absolute time basis as the corresponding seconds fields? If so, what is that basis?
  4. Is date_to inclusive or exclusive for history_orders_get and history_deals_get? If it is inclusive, what exact precision or granularity applies at the upper boundary?
  5. Do history_orders_total and history_deals_total use exactly the same time-boundary semantics as history_orders_get and history_deals_get?
  6. Are these semantics invariant across brokers and trading servers, or can a broker or trading-server configuration influence the request boundaries or the returned order and deal time values?
  7. If broker or server configuration can affect these semantics, what official method should a Python integration use to determine the convention applicable to a specific trading server?
  8. Please identify any official documentation page or specification governing your answers, if one is available.

For audit purposes, please state explicitly when a question is outside MetaQuotes’ authority or requires confirmation from the broker.

Thank you.


 
Savane Oumar:

We request an authoritative technical clarification of the time semantics used by the official MetaTrader5 Python package. This is a specification question, not account troubleshooting. The requesting environment uses MetaTrader5 Python package 5.0.5735 with MetaTrader 5 terminal build 6140.

Forum on trading, automated trading systems and testing trading strategies

Timezones in Metatrader 5: unclear Python documentation

Anthony Eric Gillon Dawson, 2024.01.31 17:45

Well it seems a bit of a mess... in my case ticks are coming out in proper Unix time UTC while M10, H1 and so on come out with a Unix timestamp shifted by broker time, in my case UTC + 2. As python thinks all Unix stamps are in UTC this causes all sorts of problems in trying to convert them back to UTC particularly if they are also subject to daylight saving! What's the best solution to convert these back to UTC with daylight savings awareness? Or perhaps I should just resample the tick data into M10 & H1 timeframes?


Forum on trading, automated trading systems and testing trading strategies

Timezones in Metatrader 5: unclear Python documentation

Anil Varma, 2025.07.23 13:48

I thought this might be useful information to forum members.

I have used following code to get Brokers time (Check with your broker, which time zone its data represented) and returned by copy_rates_range() or similar methods.

    def _downloadData(self, symbol: str, tfEnum: MT5TimeFrame, UTCFrom: datetime, UTCTo: datetime) -> pd.DataFrame:

        rates = mt5.copy_rates_range(symbol, tfEnum.value, UTCFrom, UTCTo) # <class 'numpy.ndarray'>

        if rates is None or len(rates) == 0:
            raise ValueError(f"No data returned from MT5 for {symbol} {tfEnum.name} between {UTCFrom} and {UTCTo}")

        df = pd.DataFrame(rates)

        # PepperStone: Cyprus timezone (DST-aware, same as broker/server time)
        tzPepperStone = pytz.timezone("Europe/Nicosia")

        # Convert timestamp (MT5 server time) to aware datetime
        df['DateSVR'] = pd.to_datetime(df['time'], unit='s').dt.tz_localize(tzPepperStone)
        # Also add UTC and New York time columns for clarity
        df['DateUTC'] = df['DateSVR'].dt.tz_convert('UTC')
        df['DateNYC'] = df['DateSVR'].dt.tz_convert('America/New_York')

        df = df.drop(columns=['time', 'real_volume'])
        df.set_index('DateNYC', inplace=True)
        return df

And it has given the correct results

Regards


 
Ryan L Johnson #:


Thank you for the references.

For this particular case, I need an authoritative MetaQuotes specification or official confirmation for the Python API semantics, especially for history_orders_get() / history_deals_get(), the returned ORDER_TIME_* / DEAL_TIME fields, and the date_to boundary.

Do you know of any official MetaQuotes documentation or statement that defines these semantics explicitly?


 
Savane Oumar #:

Thank you for the references.

For this particular case, I need an authoritative MetaQuotes specification or official confirmation for the Python API semantics, especially for history_orders_get() / history_deals_get(), the returned ORDER_TIME_* / DEAL_TIME fields, and the date_to boundary.

Do you know of any official MetaQuotes documentation or statement that defines these semantics explicitly?

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

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

Forum on trading, automated trading systems and testing trading strategies

Are history_orders_get() and history_deals_get() always chronologically ordered in MQL5?

fxsaber, 2023.09.13 14:58

Deals and orders are sorted by ticket numbers.

For deals this is automatically indicated that they are sorted by time.

This is not the case for orders.

Forum on trading, automated trading systems and testing trading strategies

Are history_orders_get() and history_deals_get() always chronologically ordered in MQL5?

fxsaber, 2023.09.13 17:10

Unfortunately, orders are not added in chronological order. You can delete an order, but it will not necessarily be at the end of the trading history.


The terminal developers are aware of this behavior and are not going to change it.



 
Ryan L Johnson #:

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

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



Thank you.

I have reviewed both official MetaQuotes pages you linked. They document the functions and parameters, but I cannot find an explicit statement there defining:

  • the timezone/time reference of date_from and date_to,
  • the timezone/time reference of ORDER_TIME_SETUP, ORDER_TIME_DONE, DEAL_TIME and the *_MSC fields,
  • or whether date_to is inclusive or exclusive.

Do you know of any official MetaQuotes documentation or statement that explicitly defines those points?

Thank you.


 
All of these share one basis: the trade server's time, not UTC and not local/OS time. The MT5 datetime is formed on the server and is independent of the computer clock, and the Python package returns those same epoch integers unchanged.
So date_from/date_to are interpreted in server time, and ORDER_TIME_SETUP, ORDER_TIME_DONE and DEAL_TIME are server-time seconds. The _MSC fields use the exact same absolute basis, just in milliseconds - divide by 1000 and you land on the same instant as the seconds field. Practically: get your broker's server offset (most are UTC+2/+3 with DST) and convert once at the boundary rather than assuming UTC anywhere.
 
Arnab Karmakar #:
All of these share one basis: the trade server's time, not UTC and not local/OS time. The MT5 datetime is formed on the server and is independent of the computer clock, and the Python package returns those same epoch integers unchanged.
So date_from/date_to are interpreted in server time, and ORDER_TIME_SETUP, ORDER_TIME_DONE and DEAL_TIME are server-time seconds. The _MSC fields use the exact same absolute basis, just in milliseconds - divide by 1000 and you land on the same instant as the seconds field. Practically: get your broker's server offset (most are UTC+2/+3 with DST) and convert once at the boundary rather than assuming UTC anywhere.

Thank you, this is very helpful.

Could you please point me to an official MetaQuotes documentation page or official MetaQuotes statement that explicitly confirms that history_orders_get() / history_deals_get() use trading-server time for date_from , date_to , ORDER_TIME_SETUP , ORDER_TIME_DONE , DEAL_TIME and the corresponding *_MSC fields?

Also, do you know whether date_to is inclusive or exclusive, and at what precision?

Finally, when you say the Python package returns the same epoch integers unchanged, do you mean true Unix/UTC epoch timestamps, or server-wall-clock values encoded as epoch seconds?

Thank you.

 
Alain Verleyen #:

Thank you, this is very important.

To make sure I understand correctly, does your statement also apply specifically to history_orders_get() and history_deals_get() , including date_from , date_to , ORDER_TIME_SETUP , ORDER_TIME_DONE , DEAL_TIME and the corresponding *_MSC fields?

Also, do you know whether date_to is inclusive or exclusive, and at what precision?

Finally, since you reported the datetime/timezone documentation issue to MetaQuotes, is there any official MetaQuotes ticket, updated documentation page, or confirmation that can be cited?

Thank you.

 
Savane Oumar #:

Thank you, this is very important.

To make sure I understand correctly, does your statement also apply specifically to history_orders_get() and history_deals_get() , including date_from , date_to , ORDER_TIME_SETUP , ORDER_TIME_DONE , DEAL_TIME and the corresponding *_MSC fields?

Also, do you know whether date_to is inclusive or exclusive, and at what precision?

Finally, since you reported the datetime/timezone documentation issue to MetaQuotes, is there any official MetaQuotes ticket, updated documentation page, or confirmation that can be cited?

Thank you.

The same applies to the whole API.

You need to use UTC timezone in your parameters, and the returned data are broker server time.

 
Alain Verleyen #:

The same applies to the whole API.

You need to use UTC timezone in your parameters, and the returned data are broker server time.

Thank you, that clarifies the most important distinction.

Just two remaining points for audit purposes:

  1. Is date_to inclusive or exclusive for history_orders_get() and history_deals_get() , and at what precision?
  2. Is there any official MetaQuotes ticket, documentation update, or statement that can be cited for the UTC-input / broker-server-time-output behavior?

Thank you.

New comment