Download MetaTrader 5

London Break-out

To add comments, please log in or register
Ibrahim Melssen
49
Ibrahim Melssen  

Dear forum members,

Since a few weeks I am trying to get ahead with MQL4, but what a challenge!! I was hoping I would be an expert already! but I am not and I hoping to get a little bit of help.

I am trying to build an breakout Expert advisor for the London opening session. I want my expert advisor to calculate the high and low of the 5 bars before the london open an then calculates the high and low.

For this function I assume I have to use the high of the iHigh function and the low of the iLow function to calculate the range. But this range then will be changing during the day. I want those high and low of that range to be static and not variable.

Does anyone has any ideas?

Thanks in advanced!

Tjipke de Vries
6325
Tjipke de Vries  
Nour:

Dear forum members,

Since a few weeks I am trying to get ahead with MQL4, but what a challenge!! I was hoping I would be an expert already! but I am not and I hoping to get a little bit of help.

I am trying to build an breakout Expert advisor for the London opening session. I want my expert advisor to calculate the high and low of the 5 bars before the london open an then calculates the high and low.

For this function I assume I have to use the high of the iHigh function and the low of the iLow function to calculate the range. But this range then will be changing during the day. I want those high and low of that range to be static and not variable.

Does anyone has any ideas?

Thanks in advanced!


how do you find the bar where london open starts...

show how you do it

qjol
3243
qjol  
Ibrahim Melssen
49
Ibrahim Melssen  

That's another problem deVries, I don't now how to find the bar where London opens...

I am still pretty new to MQL4

gchrmt4
356
gchrmt4  

... am I missing something, or are the date/time functions built into MQL4 still inadequate for this kind of thing?

Two issues:

* You can't reliably get the offset between the broker server and GMT because (a) it can change with daylight savings, and (b) any comparison of TimeCurrent() against TimeGMT() to calculate an offset fails over weekends.

* Even though you can get the current offset while the market is open, there is no built-in way of translating GMT time to another timezone such as London.

In other words: no built-in way of determining (a) the broker's server runs at CET, and therefore (b) London times for each bar are 1 hour behind the time reported by MT4.

Tjipke de Vries
6325
Tjipke de Vries  

Nour:

That's another problem deVries, I don't now how to find the bar where London opens...

I am still pretty new to MQL4

https://docs.mql4.com/series/ibarshift
GreenMoney
379
GreenMoney  
gchrmt4:

... am I missing something, or are the date/time functions built into MQL4 still inadequate for this kind of thing?

Two issues:

* You can't reliably get the offset between the broker server and GMT because (a) it can change with daylight savings, and (b) any comparison of TimeCurrent() against TimeGMT() to calculate an offset fails over weekends.

* Even though you can get the current offset while the market is open, there is no built-in way of translating GMT time to another timezone such as London.

In other words: no built-in way of determining (a) the broker's server runs at CET, and therefore (b) London times for each bar are 1 hour behind the time reported by MT4.


It appears that TimeGMT() does not change with Daylight Saving Time. For example, I live in the U.S., so currently my local timezone is EDT. My broker's MT4 server currently is EEST. Now, consider the following code and its output:

   Print ("1. GMT = ", TimeToString(TimeGMT()));
   Print ("2. Local Time (EDT) = ", TimeToString(TimeLocal()));
   Print ("3. Daylight Saving Adjustment: ", TimeDaylightSavings()/3600);
   Print ("4. GMTOffset for TimeLocal = ", TimeGMTOffset()/3600);
   Print ("5. Server Time (EEST) = ", TimeToString(TimeCurrent()));
   
   int local = (TimeLocal() - TimeGMT()) / 3600;
   int server = MathRound((TimeCurrent() - TimeGMT()) / 3600.0);
   string prt = "TimeLocal is ";
   if (local > 0)
      prt = StringConcatenate(prt, "GMT+", MathAbs(local));
   else if (local < 0)
      prt = StringConcatenate(prt, "GMT-", MathAbs(local));
   else
      prt = StringConcatenate(prt, "GMT");
      
   prt = StringConcatenate(prt, " and TimeCurrent is ");
   if (server > 0)
      prt = StringConcatenate(prt, "GMT+", MathAbs(server));
   else if (local < 0)
      prt = StringConcatenate(prt, "GMT-", MathAbs(server));
   else
      prt = StringConcatenate(prt, "GMT");
    
   Print (prt);

17:52:28 Expert TestEA-1 EURUSD,H1: loaded successfully

17:52:28 TestEA-1 EURUSD,H1: 1. GMT = 2014.03.11 21:52

17:52:28 TestEA-1 EURUSD,H1: 2. Local Time (EDT) = 2014.03.11 17:52

17:52:28 TestEA-1 EURUSD,H1: 3. Daylight Saving Adjustment: -1

17:52:28 TestEA-1 EURUSD,H1: 4. GMTOffset for TimeLocal = 4

17:52:28 TestEA-1 EURUSD,H1: 5. Server Time (EEST) = 2014.03.12 00:52

17:52:28 TestEA-1 EURUSD,H1: TimeLocal is GMT-4 and TimeCurrent is GMT+3

I checked the GMT time above with that of London, and they were the same (London doesn't change to BST until the end of March). So I believe that TimeGMT() returns GMT without adding local Daylight Saving Time adjustment. EDT is defined as UTC-4 and EEST is defined as UTC+3.

Also, if you need to determine when Daylight Saving Time starts and ends for the U.S. or for the EU, see these functions.

gchrmt4
356
gchrmt4  
Thirteen:

I checked the GMT time above with that of London [...]

As you almost certainly know... one of the issues is that the offset between the broker's time and GMT (a) may or may not be variable based on daylight savings and (b) whether or not it is variable cannot be determined based on information which MT4 provides. I haven't looked at these functions in any detail, but I think we're agreed that you cannot do any such calculation based solely on information which MT4 provides.

As far as I can see, at the start of April the code above will start saying that the broker is at GMT+4. My point is that there is no way of knowing from what MT4 tells you that, in the previous week, the broker was at GMT+3 and that uses of e.g. iBarShift() may need to be adjusted accordingly if you want to work out price activity at specific GMT times, or offsets of GMT times.

BTW, if you ran the above code today then your broker almost certainly cannot be on EEST. They should be on EET until March 30th. If they are currently at GMT+3 then they're using something other than EEST. (The page you linked to says "During this time of year, locations on EEST are now on EET").

GreenMoney
379
GreenMoney  

gchrmt4:

. . .

BTW, if you ran the above code today then your broker almost certainly cannot be on EEST. They should be on EET until March 30th. If they are currently at GMT+3 then they're using something other than EEST. (The page you linked to says "During this time of year, locations on EEST are now on EET").

My broker changes the timezone on its MT4 server from GMT+2 to GMT+3 to correspond to 5pm New York close, and it does so at the same time the U.S. changes to Daylight Saving Time, which happened on March 09, 2014. In Europe, GMT+2 roughly corresponds to EET for standard time, so GMT+3 corresponds to EEST for daylight saving time. See, for example, European Time Zones. So, as you can see, there is no doubt that I ran the code today when my local time zone is EDT and my broker's time zone corresponds to EEST.

[1] As far as I can see, at the start of April the code above will start saying that the broker is at GMT+4.

[2] My point is that there is no way of knowing from what MT4 tells you that, in the previous week, the broker was at GMT+3 and that uses of e.g. iBarShift() may need to be adjusted accordingly if you want to work out price activity at specific GMT times, or offsets of GMT times.

1. Why would it return GMT+4 in April? My local computer's time is already adjusted for daylight saving time, and my broker has already adjusted its server to reflect daylight saving time, so what will change in April?

2. A broker may change its time to reflect daylight saving time, which would change its offset to GMT. But you can predict that change. For example, while the dates/times that daylight saving time starts and ends changes from year to year, that change is predictable--and therefore programmable. Just code the rule. But TimeGMT() should return GMT regardless of local time zone, broker time zone, or daylight saving time offset.

As you almost certainly know... one of the issues is that the offset between the broker's time and GMT (a) may or may not be variable based on daylight savings and (b) whether or not it is variable cannot be determined based on information which MT4 provides. I haven't looked at these functions in any detail, but I think we're agreed that you cannot do any such calculation based solely on information which MT4 provides.

If a broker adjusts for daylight saving time, then that adjustment would change its offset to GMT, but as I stated above, you can predict those changes and adjust for them. Or if a place (for example, London) adjusts for daylight saving time, you can code the local rule and thereby predict that change and adjust for it.

gchrmt4
356
gchrmt4  
Thirteen:

If a broker adjusts for daylight saving time, then that adjustment would change its offset to GMT, but as I stated above, you can predict those changes and adjust for them. Or if a place (for example, London) adjusts for daylight saving time, you can code the local rule and thereby predict that change and adjust for it.

I'm still fundamentally agreeing with you that the changes are predictable and codeable... but not solely using information which MT4 itself provides. You have to "code the local rule" for London GMT, rather than saying to MT4 "give me the equivalent time for x in London".

Your server time of GMT+3 may correspond to EEST in the sense that EEST is GMT+3 but, according to both Wikipedia and worldclock.com, nowhere should be on EEST yet. That change shouldn't happen until March 30th. The current time in Cyprus, Greece, Israel etc is GMT+2.

Therefore, what you probably have is a broker running its servers at GMT+2, but changing to daylight savings on the US dates rather than the European dates. That's not the same as EET/EEST. (And it's even less predictable in terms of being able to write code which automatically adjusts times and dates without having to ask the user for some kind of input about what time settings the broker uses.)

If, therefore, the broker has recently changed from GMT+2 to GMT+3, rather than being about to change from GMT+3 to GMT+4, what it means is that the current offset between broker time and GMT would be wrong if you tried to apply it to bars last week, before the US clock change. This week, the broker's bars are 3 hours ahead of London. Last week they were 2 hours ahead. (And, from March 30th, they will be 2 hours ahead again.) If you take that current offset of 3 hours and use it to try to get the price at 8am London time on a day last week, you will get the wrong answer.

All I'm saying is that the information which it is possible to get just from MT4 itself - current offset between broker time and GMT - is inadequate in practice for doing things like saying "work out the opening price in London last Wednesday".

Ian Venner
2584
Ian Venner  

How could MT4 be made more adequate for doing that ? I don't know about you but I sure wouldn't relish the task of creating a regional historical GMT offset calculator. Can you just imagine ? omg. If I ever do I'll put it on the market you all better have a big fat cheque book ;)

Im just kidding, theres no way im attempting to code that. WHR could do it though, I bet he already has.

123
To add comments, please log in or register