Discussion of article "Dealing with Time (Part 2): The Functions"

 

New article Dealing with Time (Part 2): The Functions has been published:

Determing the broker offset and GMT automatically. Instead of asking the support of your broker, from whom you will probably receive an insufficient answer (who would be willing to explain a missing hour), we simply look ourselves how they time their prices in the weeks of the time changes — but not cumbersome by hand, we let a program do it — why do we have a PC after all.

Before the functions in the include file DealingWithTime.mqh (and after the macro substitution) the required variables are declared as global variables:

//--- global variables for time switches
int      DST_USD=0,                             // act time shift USD
         DST_EUR=0,                             // act time shift EU
         DST_AUD=0,                             // act time shift Australia
         DST_RUS=0;                             // D'2014.10.26 02:00', -10800,

These variables DST_USD, DST_EUR,.. will have the actual time shift of the USA, the EU,.. They will be updated and set by our functions. In the winter time which is the normal time they are zero: the time is not shifted at that period.

After that we have the variables with the next time the time changeover will take place. They are is mainly needed to know when a new calculation is required in order to save the CPU resources:

datetime nxtSwitch_USD,                         // date of next switch
         nxtSwitch_EUR,                         // date of next switch
         nxtSwitch_AUD,                         // date of next switch
         nxtSwitch_RUB = D'2014.10.26 02:00';   // Russia s different :(

We will consider the Russian situation later in this article.

This structure and its global variable is the heart of all. :)

struct _OffsetBroker
  {
   int   USwinEUwin,                            // US=Winter & EU=Winter
         USsumEUsum,                            // US=Summer & EU=Summer
         USsumEUwin,                            // US=Summer & EU=Winter
         actOffset,                             // actual time offset of the broker
         secFxWiWi,                             // duration of FX in sec
         secFxSuSu,                             // duration of FX in sec
         secFxSuWi,                             // duration of FX in sec
         actSecFX;                              // actual duration of FX in sec
   bool  set;                                   // are all set?
  };
_OffsetBroker OffsetBroker;

We will assign the broker offsets for the three relevant periods and duration of the forex market is open in these periods, for both the actual value and for an easy check set if the values has been assigned. The global variable is named OffsetBroker, we will meet it several times.

Author: Carl Schreiber

 
We are willing to introduce the actual values to all our fox traders to display 
 
We are willing to introduce the actual value to all our fox trade to display 
 

Hello,

As I understand from the article, the function "setBokerOffset ()" should work in the strategy tester as well, but it doesn't work.

void OnTick()
  {
//---
   bool isTimeSet = setBokerOffset();
   if(!isTimeSet)
     {
      Alert("setBokerOffset failed");
      return;
     }
  }
array out of range in 'DealingWithTime.mqh' (201,21)


Does the "The Alternative using it via Input Variables" the only way to get correct times in the strategy tester?

 
Nauris Zukas #:

Hello,

As I understand from the article, the function "setBokerOffset ()" should work in the strategy tester as well, but it doesn't work.


Does the "The Alternative using it via Input Variables" the only way to get correct times in the strategy tester?

I guess that the Strategy Tester hasn't got the quotes and then prev. CopyTime() failed. Check whether the requested and needed data are already locally available.
 
Carl Schreiber #:
I guess that the Strategy Tester hasn't got the quotes and then prev. CopyTime() failed. Check whether the requested and needed data are already locally available.

Ok, I will watch closer CopyTime() and will try to resolve it.

And thank you, very useful article!

 
Good article. However, one problem arises: how to determine that a broker/dealer is switching from winter/summer without contacting its technical support?
 
Nikita Chernyshov # :
Good article. However, one problem arises: how to determine that a broker/dealer is switching from winter/summer without contacting its technical support?
  1. Why not ask?
  2. The software knows when summer/winter time is in the US and EU and uses that to calculate the broker's offset.
 
Nikita Chernyshov #:
Good article. However, one problem arises: how to determine that a broker/dealer is switching from winter/summer without contacting its technical support?


.
Документация по MQL5: Дата и время / TimeDaylightSavings
Документация по MQL5: Дата и время / TimeDaylightSavings
  • www.mql5.com
TimeDaylightSavings - Дата и время - Справочник MQL5 - Справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5
 
Alexey Viktorov #:


.

yes, but depends on the user's time settings, which doesn't work out very well. Moreover, it needs to be modelled in a tester.

 
Carl Schreiber #:
  1. Why not ask?
  2. The software knows when summer/winter time is in the US and EU and uses that to calculate the broker offset.

1. Because support doesn't always give correct information. You yourself pointed this out about the Alpari dealer. + it is overhead: to find out from each dealer the transition. Because then you can't create a good solution, I don't know who the end user is discussing with.

2. Well, sort of, yes, but if the dealer does not transition from winter to summer and back, then you get some strange thing in the calculations.

I tried to modify your library a bit, but apparently something went wrong. I thought that the code should lead to the fact that the Expert Advisor automatically detects GMT time and trades according to GMT, not according to the broker's server. I am not sure if the code is optimal, but the solution seems to work. However, in those dealers that do not change the time - there are some incorrect calculations.