London Break-out - page 2

New comment
 

Yes, all because of IMO a puzzling design decision :) So servertime may not even correspond to any known world clock over the course of a year.

I've got one method to accurately determine GMT time, esp during backtesting. This method appears to work for brokers that

  • have changed TZ in the middle of their historical data (Alpari),
  • or use non standard DST against their timezone (FXCM) as Thirteen points out,

but the approach still feels a little hackish to me.

It involved downloading GMT based quotes from other sources (dukascopy), and comparing the hour of each daily high. Works OK for backtesting, but at present I'm manually downloading the hour data, and filtering the highs (using a perl script).

Once I can automatically get GMT H1 quotes from at least two sources then I'll be comfortable with this approach for my purposes.

 
SDC:

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 ;)

A historical GMT calculator isn't in itself particularly hard (the Windows operating system already contains all the data you need), but isn't the primary issue. The problem is that you can determine the current offset between broker time and GMT, but you don't know if/when it changed. Using the example above, you can see that the broker is currently on GMT+3 (assuming that the local computer clock is accurate...), but you don't know that the broker was on GMT+2 last week.

It's very possible that the MT4 client terminal simply doesn't have this information.

If it did have it, then MT4 could provide either the bare data which you could process yourself, or a function which let you say "convert any broker date in the past to GMT". Once you had that, you could use a lookup table (or the Windows API) to convert that historic GMT time to another timezone such as London. However, it would be preferable for MT4 to do this for you as well, e.g. a pair of functions such as the following:

datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);

datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);

 
ydrol:

Yes, all because of IMO a puzzling design decision :)

(I assume that the reason for not fixing on UTC is so that brokers can run at EET giving five D1 candles per week, avoiding a sixth small candle which leads to systemic underestimates of things like D1 ATR on brokers who use GMTZ.)
 
gchrmt4:
(I assume that the reason for not fixing on UTC is so that brokers can run at EET giving five D1 candles per week, avoiding a sixth small candle which leads to systemic underestimates of things like D1 ATR on brokers who use GMTZ.)


I would have put all that stuff in the client, but it makes the client more complicated in different places :) But at least all variables are known.
 

Another approach, according to this page there are only 62 MT4 brokers? So it wouldn't be too hard to just have a lookup table for each broker and their definition of time (whether it is based on a real timezone or a combination ala FXCM), and also incorporate historical changes (ala Alpari).

This is probably the most robust approach, and just will need tweaking every time a broker decides it wants to confuse its clients a little more :)

 

gchrmt4:

[1] 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.

[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.

[3] 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.)

  1. Correct.
  2. Correct.
  3. EET is GMT+2, but GMT+2 is not only EET. Also, EEST is GMT+3, but GMT+3 is not only EEST. By describing my broker's time zone as EET/EEST, I only meant to infer that it was GMT+2 while in standard time and GMT+3 while in daylight saving time, especially since this thread discusses the London breakout. I apologize if my description has led to some confusion. :)

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.

A broker generally doesn't change it's server's time zone often, except to adjust for daylight saving time. For the daylight saving adjustment, I can use any date/time (from the 1987 (U.S.) and 1996 (EU) to 2020 and beyond) and calculate, for the U.S. and the EU, the day daylight saving time starts and the day daylight saving time ends. Once you have that code, all you have to is adjust the current offset to GMT to accommodate daylight saving time for the time you are looking at.

With TimeGMT(), which is new in build 600+, you calculate your broker's current offset to GMT. But one can't (as far as I know) determine a broker's time zone from the past. For example, I had a broker change it's server's time zone from GMT for standard time to GMT+2 for standard time. I dealt with that by hard coding an offset for time before the switch because all of the history data was GMT, not GMT+2 (and I didn't want to modify the history to reflect GMT+2). In that regard, I believe you and I agree. So long as a broker doesn't just change time zones (other than to adjust for daylight saving time), you should be able to calculate the offset to GMT and adjust that offset for daylight saving time.

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".

I believe I disagree with you. So long as the broker doesn't change time zones, except for adjusting for daylight saving time, you can determine the offset to GMT, both for current time and for historical time. If, last week during standard time, the broker is GMT+2 and London is GMT, then 8am London time would be 10am server time. Next month, during daylight saving time, when broker is GMT+3 and London is GMT+1, 8am London time would correspond to 10am server time. Today, when broker is on daylight saving time and London is on standard time, the broker is GMT+3 and London is GMT, so 8am London time would be 11am server time.

If the broker is GMT-5 (EST) and London is GMT, 8am London time is 3am server time.

 
gchrmt4:

A historical GMT calculator isn't in itself particularly hard (the Windows operating system already contains all the data you need), but isn't the primary issue. The problem is that you can determine the current offset between broker time and GMT, but you don't know if/when it changed. Using the example above, you can see that the broker is currently on GMT+3 (assuming that the local computer clock is accurate...), but you don't know that the broker was on GMT+2 last week.

It's very possible that the MT4 client terminal simply doesn't have this information.

If it did have it, then MT4 could provide either the bare data which you could process yourself, or a function which let you say "convert any broker date in the past to GMT". Once you had that, you could use a lookup table (or the Windows API) to convert that historic GMT time to another timezone such as London. However, it would be preferable for MT4 to do this for you as well, e.g. a pair of functions such as the following:

datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);

datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);


Yes it would not be difficult if there were no DST, but there is lol... it would be a nightmare to code. Historical anomalies would be everywhere. Regions that changed the timezone they use, regions that experimented with not using DST at all then reverted back to DST, regions that respect DST in some places but not others, there would be so many anomolies to take into consideration, all around the world ...
 
ydrol:

Another approach, according to this page there are only 62 MT4 brokers? So it wouldn't be too hard to just have a lookup table for each broker and their definition of time (whether it is based on a real timezone or a combination ala FXCM), and also incorporate historical changes (ala Alpari).

62 is an under-estimate, and the bigger brokers have servers set to different timezones.
 

Thirteen:

If, last week during standard time, the broker is GMT+2 and London is GMT,

How, using only the information which MT4 provides, do you know that the broker was on GMT+2 last week?
 

The common sense approach would be for MT4 server to use GMT all the time but you know they aren't going to do that.

123
New comment