Strange behaviour of timeframe on two different brokers

 

Hi Guys,

I was backtesting my EA on two different brokers ( all two  proposed by terminal in two different PC)  , brokers are specifically : AMPGlobal  ( IP=78.140.180.54 located in netherland)  and MetaQuotes-Demo IP=78.140.180.48  located in netherland )

the problems is that I started the EA with a TF =H4  and :

  1. If I am logged on the first server ( AMPGlobal)  I get the right parameters to open a buy position  isnewbar() at  timecurrent of 2023.01.06 20:00:01 with price of 1.0571X  
  2. If I am logged on the second server ( MetaQuotes-Demo)  I didn't get the right parameters to open  at the same TF-H4,  isnewbar(). 
    So I put a debug at every hour and i found  right  timecurrent  2023.01.06 22:00:00 ask price:1.0571X  <--- TWO Hours later

How this is possible ? At first sight i tought  was a broker location time. 

someone could give some light on this. Am i wrong using Timecurrent ?  Supposing that every broker download their own data,  the way they treat this data with TF must be the same, isn't it?

This is struggeling my head because  I am non sure if i change the demo account in a real accont my strategy work the same way.

thanks you all,

Documentation on MQL5: Constants, Enumerations and Structures / Environment State / Account Properties
Documentation on MQL5: Constants, Enumerations and Structures / Environment State / Account Properties
  • www.mql5.com
Account Properties - Environment State - Constants, Enumerations and Structures - MQL5 Reference - Reference on algorithmic/automated trading language for MetaTrader 5
 

Ask you broker what is their server time with or without DST.

You can read about it in my time articles:

https://www.mql5.com/en/articles/9926
https://www.mql5.com/en/articles/9929

Dealing with Time (Part 1): The Basics
Dealing with Time (Part 1): The Basics
  • www.mql5.com
Functions and code snippets that simplify and clarify the handling of time, broker offset, and the changes to summer or winter time. Accurate timing may be a crucial element in trading. At the current hour, is the stock exchange in London or New York already open or not yet open, when does the trading time for Forex trading start and end? For a trader who trades manually and live, this is not a big problem.
 

Chart times are broker times.

  1. How can MetaQuotes know all brokers' (they come and go daily) Time zone and Daylight savings time (if they use it and including historical changes for back testing)? Do you have that information for just you and your broker? Only then, with code, can you convert session times to broker's time to UTC to local time. You can use offset inputs, but then you must maintain them correctly, through all three DST changes when they occur.
              When is the time zone problem going to be fixed? - General - MQL5 programming forum (2020)

  2. Foreign Exchange (FX) market opens 5 PM New York (NY)/Eastern Time (ET) Sunday and ends 5 PM NY Friday. Some brokers start after (6 PM is common) and end before (up to 15 minutes) due to low volatility.
              Checking for Market Closed - Expert Advisors and Automated Trading - MQL5 programming forum (2016)

    Swap is computed 5 PM ET. No swap if no open orders at that time.

  3. Brokers use a variety of time zones. Their local time, with or without Daylight Savings Time (DST), London, UTC, London+2, UTC+2, NY+7.

    Only with NY+7 does the broker's 00:00 equals 5 PM ET and the start of a daily bar (and H4) is the start of a new FX day.

    GMT/BST brokers, means there is a 1 or 2 hour D1/H4 bar on Sunday (depending on NY DST), and a short Friday bar. (Problems with indicators based off of bars.)

    GMT+2 is close but doesn't adjust for NY DST.

    EET is closer, except when their DST doesn't match NY's. Last Sunday of March and 1:00 on the last Sunday of October vs second Sunday in March and return at 2:00 AM EDT to 1:00 AM EST on the first Sunday in November.

  4. Non-NY+7, means the chart daily bar overlaps the start, and converting broker time to NY time requires broker to UTC to NY timezone conversions.


  5. If you search the web, you will find differing answers. Those are all wrong (half the year) because they do not take DST into account (or that it changed for the US in 2007 [important when testing history.])


  6. Then there are (non-24 hour markets) with H4 candles that start on odd hours.
              Why My XAUUSD 4H candles start with 1 hour shift? - Currency Pairs - General - MQL5 programming forum (2019)
              H4 first opened candle - MT5 - General - MQL5 programming forum (2020)

    And H1 on the half hour.

  7. See also Dealing with Time (Part 1): The Basics - MQL5 Articles (21.10.01)
    and Dealing with Time (Part 2): The Functions - MQL5 Articles (21.10.08)

 
Thank you guys for the quick response.

I did immagine that the problem could be related to times. 

For sure i take the time to read the two articles suggested  (   https://www.mql5.com/en/articles/9926  and https://www.mql5.com/en/articles/9929 ) but before i do that let me know about a couple of things.

  1. In my case all two brokers are locate in netherland. ( what we are talking about ? ) . Would you say that one of this brokers has set time server differently as the nation time server ?

  2. If this is true is evident that one's own  strategy could not function if you change broker. ( at least for what that is turning out ).

  3. Taking all this in to account what is you suggestion state that the candles are opened/close at the broker time ??

thanks 

Dealing with Time (Part 1): The Basics
Dealing with Time (Part 1): The Basics
  • www.mql5.com
Functions and code snippets that simplify and clarify the handling of time, broker offset, and the changes to summer or winter time. Accurate timing may be a crucial element in trading. At the current hour, is the stock exchange in London or New York already open or not yet open, when does the trading time for Forex trading start and end? For a trader who trades manually and live, this is not a big problem.
 
jossnet #: Would you say that one of this brokers has set time server differently as the nation time server ?
I said, in #2.3: “Brokers use a variety of time zones.” Did you ignore it, not understand it, or was it not clear?
 

Hi William, thanks for replay ..

 Did you ignore it, not understand it, or was it not clear?


As you have read in my post , I said  "  For sure i take the time to read  ----- but before i do that let ...." So when I posted I didn't still read ....

Now I read the two articles of Carl ( and I also thank him for the excellent explantion ) and I've got the idea (and the certainly ) that without it I don't go anywhere.

that said, I try to do the implementation and verify all the mechanisms.
thanks for now.

 

Hi William ,

I finally add "DealingWithTime.mqh" class to my project and  then i tested the with command  setBokerOffset()   as reported in the conclusion part of the article-2 :

Well :  I have several problems to undertand with your help .

First  :when I debug with first server ,  using funcions in   "DealingWithTime.mqh I get  this values :

2023.05.09 00:04:08.917 2023.01.04 00:00:00   2nd half-year 2020 for AMP Global Ltd. DebugMode: 0
2023.05.09 00:04:08.917 2023.01.04 00:00:00   EUR: Tu.2023.01.03 23:00: hNY:16  hGMT:21  hTC:23  hDiff:-2   BrokerTime => GMT: 2023.01.03 21:00 => tNY: 2023.01.03 16:00  End-FX after: 71h
2023.05.09 00:04:08.917 2023.01.04 00:00:00   USD: Tu.2023.01.03 23:00: hNY:16  hGMT:21  hTC:23  hDiff:-2   BrokerTime => GMT: 2023.01.03 21:00 => tNY: 2023.01.03 16:00  End-FX after: 71h
2023.05.09 00:04:08.917 2023.01.04 00:00:00   NXT: Tu.2023.01.03 23:00: hNY:16  hGMT:21  hTC:23  hDiff:-2   BrokerTime => GMT: 2023.01.03 21:00 => tNY: 2023.01.03 16:00  End-FX after: 71h
2023.05.09 00:04:08.917 2023.01.04 00:00:00   
2023.05.09 00:04:08.917 2023.01.04 00:00:00   Time Offset of AMP Global Ltd.: 
2023.05.09 00:04:08.917 2023.01.04 00:00:00   US=Winter & EU=Winter (USwinEUwin) = -7200
2023.05.09 00:04:08.917 2023.01.04 00:00:00   US=Summer & EU=Summer (USsumEUsum) = -2147483648
2023.05.09 00:04:08.917 2023.01.04 00:00:00   US=Summer & EU=Winter (USsumEUwin) = -2147483648

Second , when   I debug with second  server ,  using funcions in   "DealingWithTime.mqh I get  this values :

2023.05.09 00:08:40.069 2023.01.04 00:00:00   2nd half-year 2020 for MetaQuotes Software Corp.DebugMode: 0
2023.05.09 00:08:40.069 2023.01.04 00:00:00   EUR: Tu.2023.01.03 23:00: hNY:16  hGMT:21  hTC:23  hDiff:-2   BrokerTime => GMT: 2023.01.03 21:00 => tNY: 2023.01.03 16:00  End-FX after: 71h
2023.05.09 00:08:40.069 2023.01.04 00:00:00   USD: Tu.2023.01.03 23:00: hNY:16  hGMT:21  hTC:23  hDiff:-2   BrokerTime => GMT: 2023.01.03 21:00 => tNY: 2023.01.03 16:00  End-FX after: 71h
2023.05.09 00:08:40.069 2023.01.04 00:00:00   NXT: Tu.2023.01.03 23:00: hNY:16  hGMT:21  hTC:23  hDiff:-2   BrokerTime => GMT: 2023.01.03 21:00 => tNY: 2023.01.03 16:00  End-FX after: 71h
2023.05.09 00:08:40.069 2023.01.04 00:00:00   
2023.05.09 00:08:40.069 2023.01.04 00:00:00   Time Offset of MetaQuotes Software Corp.: 
2023.05.09 00:08:40.069 2023.01.04 00:00:00   US=Winter & EU=Winter (USwinEUwin) = -7200
2023.05.09 00:08:40.069 2023.01.04 00:00:00   US=Summer & EU=Summer (USsumEUsum) = -2147483648
2023.05.09 00:08:40.069 2023.01.04 00:00:00   US=Summer & EU=Winter (USsumEUwin) = -2147483648


So as you can see the result values  with  timecurrent()  and shift time are the same.

So i resume my original post, that was : "why I get different values in timeframe if ( and certified )  timeframe  are the same, I  mean how is possibile ?.

How can I know , in advance, if a broker send  different timeframe's  values  with the same H4 Period set?  I don't know if I am wrong or my point of view is wrong  but with these result it feels like an obstacle course jump to me.


Other question are the functions in  DealyWithTime , specifically I don't understand this code and i need help :

#include <DealingWithTime.mqh>
// offsets of MetaQuotes demo account: DO NOT USE THEM FOR DIFFERENT BROKERS!!
input int   USwinEUwin=  -7200;    // US=Winter & EU=Winter
input int   USsumEUsum= -10800;    // US=Summer & EU=Summer
input int   USsumEUwin=  -7200;    // US=Summer & EU=Winter


This  ( if I am not wrong)  get me in confusion because  I was expetting that these values shuold be calculated based on the timeCurrent() of broker. 
Reading the article , at the end , "in conclusion part Carl says  :

"Instead of some final words just the results of (only) the function setBokerOffset() applied to demo accounts of several brokers:"

If I have to set manually these values with every broker is something i was not expecting. I appreciate the excellent article but I have to ask to Carl some more light on this.


EDIT : 09-05-23 

I try to explain better ;

Given this situation ( i remind we are in strategy tester ..with downloaded data ):

  //=============================
  //the function :
	datetime tB = TimeCurrent();
        nextDST("EUR",tB);  //-->  calculate DST_EUR   
        nextDST("USD",tB);  //-->  calculate DST_USD  and then in
        checkTimeOffset()   //-->  set .actOffset with 
                OffsetBroker.actOffset = OffsetBroker.USwinEUwin; // based on DST_XXX
        ::::
    // so we cacl the various dates ...     
    tGMT  = tB + OffsetBroker.actOffset;         // GMT
    tNY   = tGMT - (NYShift+DST_USD);                  // time in New York
    tLeft = OffsetBroker.actSecFX - SoW(tB);     // time till FX closes

The problem seems to me that the value OffsetBroker.USwinEUwin is only calculated in chckFriday() inside the   setBokerOffset() function.

So , I think, if we take a date tB  and want to know what are the 3 vaues  .USwinEUwin , .USsumEUsum and .USsumEUwin  we have to execute for every date  setBokerOffset() function ??  or at least  chckFriday()  ??

Of course , I can change it , but i wanted to know if it's the correct logic i read ?
Also , for how long time these 3 values ( .USwinEUwin , .USsumEUsum and .USsumEUwin  ) are valids ??
do I have every now and then to change these values manually ??


Correct me if I am wrong or I misunderstand something.

All that said , the functionality in  DealyWithTime  are a good behaviour  but ( my opinion ) doesn't resolve the question why two brokers with the same time shift have different data at the same TF.

 
  1. The time offset everywhere in the world changes only on Sundays when (normally) no trading session is open.
  2. The change of DST happens only twice a year. If you know these weekends it is enough to calculate DST only twice a year and not on every tick.
  3. So if an EA is started it calculates the actual broker time offset and provides as well the locale times of GMT, NY, ....
  4. If you need 'real world times' don't use broker time but GMT +/- the requested local offset.
 

Hi Carl , thanks for replay,

As i said to William the problem i faced I don't think is related to broker's time shift. But when I posted my problem William has  "thought /decide" that was a  broker's time shift and then gave me all the medicines for this kind of problem.
I really appreciate you article and I took the solution you provide in my projects.
I just noticed reading your code that the 3 variables  ( .USwinEUwin , .USsumEUsum and .USsumEUwin  ) are just set once for the life time , but in 
checkTimeOffset() they are used according to DST_XXX values and ( my opinion ) when a date in checkTimeOffset() function cross DST for the country  the 3 values have to be updated.
So my question is  when these values  are updated. ??

That said , I need help to my main problem posted above :

  1. If I am logged on the first server ( AMPGlobal)  I get the right parameters to open a buy position  isnewbar() at  timecurrent of 2023.01.06 20:00:01 with price of 1.0571X  
  2. If I am logged on the second server ( MetaQuotes-Demo)  I didn't get the right parameters to open  at the same TF-H4,  isnewbar(). 
    So I put a debug at every hour and i found  right  timecurrent  2023.01.06 22:00:00 ask price:1.0571X  <--- TWO Hours later

after hours of fight and have read lots of post here and there I am pretty sure the problem rely on iMA Indicator I use, specifically :

int FastEMA = 21;							// EMA FastEMA period length 
int SlowEMA = 55;							// EMA SlowEMA period length 

int OnInit()
{
   fast_handle = iMA(symbol, PERIOD_H1, FastEMA, 0, MODE_EMA, PRICE_CLOSE);             // exponential mode
   slow_handle = iMA(symbol, PERIOD_H1, SlowEMA, 0, MODE_EMA, PRICE_CLOSE);             // exponential mode

::::


int OnTick()
{
    ArraySetAsSeries(fastEMA, true);
    ArraySetAsSeries(slowEMA, true);

    CopyBuffer(fast_handle, 0, 0, 2, fastEMA);  // 
    CopyBuffer(slow_handle, 0, 0, 2, slowEMA);  // 

   double fast_current  = fastEMA[0];           // on 21 candles             // HELP :: https://www.mql5.com/en/forum/438834&nbsphttps://www.mql5.com/it/articles/3040
   double fast_previous = fastEMA[1];					   // https://www.mql5.com/en/forum/357958

   double slow_current  = slowEMA[0];           // on 55     
   double slow_previous = slowEMA[1];

   // ==== here is the problem =====
   // fast_current , fast_previous , slow_current  ,slow_previous in a specific TF are not the same if I am logged with different brokers...
   // givin that the launch's parameters are the same ...
 

In my original post I forget to say that I set the chart to  TF-H4  but IMA indicators to TF-H1, even though I think this is not a problem.

At the end  if the tester download the same number of ticks in a period and gived that number of candles to analize are same in H4 as the ones in H1  how can IMA give me different results ??

Please ,help me to understand what's wrong.




 
  1. In MQL5 all higher timeframe candles are calculated from M1 candles.
  2. Different broker have different liquidity provider so they have different historical data, e.g. a broker in Asia has probably more ticks in the (EU-) night session.
  3. Have you checked that this is correct:
       double fast_current  = fastEMA[0];  // <= current
       double fast_previous = fastEMA[1]; // <= previous???
  4. In the Editor place your cursor on CopyBuffer and press F1 => understand the orientation of the requested data in the array.
 

Hi Carl, thanks ,

I didn't know this function "oeder_calc_margin", but in my case doesn't help. 

Also I didn't know about the number of ticks from broker to  broker. What I am bewildred is that  if I ask to iMA() to calulate the moving average at 16:00 for 21 candles the value must be the same in either brokers ? 
the candles on chart must be the same  either brokers.

Possible that anyone has not experienced this beaviour ?? Is this case so rare ?

Do you know any workarount for this?

thanks 

EDIT : 12.32
I have tried to go deeper , so I take I picture of the two charts so that the hours  are align vertically . With my surprice i saw that what happen in the bottom chart ( AMP) at 16.00 happen in the upper (ICT) , but 3 hours later.
here I reported the starting log for the two brokers: test period id 23-01-02 to 23-05-03

//================= ICMarketsEU-Demo 

2023.05.10 16:47:36.763 EURUSD,H4: history cache allocated for 2081 bars and contains 1554 bars from 2022.01.03 00:00 to 2022.12.30 20:00
2023.05.10 16:47:36.763 EURUSD,H4: history begins from 2022.01.03 00:00
2023.05.10 16:47:36.770 EURUSD,H4 (ICMarketsEU-Demo): generating based on real ticks

2023.05.10 16:47:36.962 EURUSD,H1: history cache allocated for 8324 bars and contains 6215 bars from 2022.01.03 01:00 to 2022.12.30 23:00
2023.05.10 16:47:36.962 EURUSD,H1: history begins from 2022.01.03 01:00

//================= AMPGlobalEU

2023.05.11 09:50:26.849 EURUSD,H4: history cache allocated for 2132 bars and contains 1613 bars from 2022.01.02 20:00 to 2023.01.01 20:00
2023.05.11 09:50:26.849 EURUSD,H4: history begins from 2022.01.02 20:00
2023.05.11 09:50:26.884 EURUSD,H4 (AMPGlobalEU-Demo): generating based on real ticks

2023.05.11 09:50:27.053 EURUSD,H1: history cache allocated for 8317 bars and contains 6242 bars from 2022.01.02 22:00 to 2023.01.01 23:00
2023.05.11 09:50:27.053 EURUSD,H1: history begins from 2022.01.02 22:00


Can this occur just on the backtesting environment.  If i try it in demo account could the problem  vanish ??

Files:
Reason: