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

New comment
 
Nikita Chernyshov # :

1. Because support does not always give correct information. You yourself pointed this out about the Alpari dealer. + it's expensive: 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 a dealer does not switch from winter to summer and back, then the calculations get a bit weird.

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.

  1. What did you change?
  2. Can you name me a broker (link) where it doesn't work?
  3. I just used it again:
     for (i=start; i<rates_total && ! IsStopped (); i++) {
      checkTimeOffset( time[i]);
      tGMT           = time[i] + OffsetBroker.actOffset; // GMT 

}


     
    Carl Schreiber #:
    1. What have you changed?
    2. Can you name me a broker (link) where it doesn't work?
    3. I just used it again:


      1.

      - I did not fixate on EURUSD, we take the pair wherever the EA is placed.

      - I did not fix the time either, I just subtract 1 year from the current one.

         datetime setDate = StringToTime(IntegerToString(NowYear()-1)+".06.21 14:00");

   nextDST("EUR", setDate);                        // EUR: get DST and set next change

      And I pass the parameters to bool setBokerOffset(string symbol, int &USwinEUwin1, int &USsumEUsum1, int &USsumEUwin1) to get this block dynamically.

      input int   USwinEUwin=  -7200;    // US=Winter & EU=Winter
input int   USsumEUsum= -10800;    // US=Summer & EU=Summer
input int   USsumEUwin=  -7200;    // US=Summer & EU=Winter

      2. alpha forex. I can in lis give data from demo account so you can check without opening anything. The thing is that the dealer does not switch from winter to summer, and the difference with GMT still occurs.

      3. a little unclear how and where the design is used.

       

      3. Немного не понял, как и где использована конструкция.

      In an indicator that is the top of the loop though all bars.

       
      In general, I switched to Greenwich. I define the time of transition to winter time as the difference between the server time and Greenwich Mean Time. The only thing is that for each broker this difference has to be calculated by myself and entered into the constants of the Expert Advisor. Just when users have different shifts, brokers, exchanges, and the time of transition to winter is not the same, Greenwich is the same for all.
       
      Valeriy Yastremskiy #:
      In general, I switched to Greenwich. I define the time of transition to winter time as the difference between the server time and Greenwich Mean Time. The only thing is that for each broker this difference has to be calculated by myself and entered into the constants of the Expert Advisor. Just when users have different shifts, brokers, exchanges, and the time of transition to winter time is not the same, Greenwich is the same for all.

      How exactly did you do it? How are the constants calculated?

       
      Nikita Chernyshov #:

      How exactly did you do this? How are the constants calculated?

      Greenwich time minus timecarrent, with the transition to winter time it will change by an hour. I wrote once the time of the start and end of work, with the client the difference in hour +3 and +2, brokers +3, +2, -6 Greenwich time))))). And it was necessary to start work at a certain time, the same for all. Greenwich Mean Time is the same, but server and local time are different. I redid the code from Fedoseyev's textbook).

      In general, the problem is that there is no standard function for the difference between server time and Greenwich time. But it is counted. There is also a problem that local time can also have a transition to winter time, and at a different time from the broker's transition.

      // TimeGMT()-TimeCurrent(); one value in summer, another in winter.
// TimeGMTOffset() =  TimeGMT() - TimeLocal(); серверным временем нет штатной функции




          
#property strict


      //+------------------------------------------------------------------+
class CTradeTimeGMT{
protected:
int StartTime;
int EndTime;
int GMTShiftTest;
int GMTShiftCur;
public:
void Init(int StartHour, int StartMinute, int EndHour, int EndMinute, int GMTshift){
StartTime=3600*StartHour+60*StartMinute;
EndTime=3600*EndHour+60*EndMinute;
GMTShiftCur=GMTshift;
GMTShiftTest=GMTshift+int((TimeGMTOffset())/3600);
//Alert(TimeGMTOffset()); 
if(MQLInfoInteger( MQL_TESTER))GMTShiftCur=GMTShiftTest;
}
bool Check(int GMTshift){
int CurTime=(int)((TimeGMT()+(GMTShiftCur*3600))%86400);
if(StartTime<EndTime){
return(CurTime>=StartTime && CurTime<EndTime);
}
else{
return(CurTime>=StartTime || CurTime<EndTime);
}
}
};
       
      Valeriy Yastremskiy #:

      Greenwich time minus timecarrent, with the transition to winter time it will change by an hour. I wrote once the time of the start and end of work, with the client the difference in hour +3 and +2, brokers +3, +2, -6 Greenwich time)))). And it was necessary to start work at a certain time, the same for all. Greenwich Mean Time is the same, but server and local time are different. The code from Fedoseyev's textbook has been reworked).

      In general, the problem is that there is no standard function for the difference between server and Greenwich time. But it is counted. There is also a problem that local time can also have a transition to winter time, and at a different time from the broker's transition.

      Thanks, yes, this solution is in my head, it is +- so implemented. But you pointed out the pain in the last paragraph)

       

      Hi @Carl Schreiber Happy New Year.

      I know this article has been up for a while, but I just found it.  Thank you for sharing this work.  It requires me to do some testing with it to really understand it.  But, I have a simple question for now:

      I can see that you have a different day of week calculation rather than relying on the MqlDateTime struct .day_of_week.  Why are you using this other calculation method, is there an accuracy benefit?  Or is it just to avoid the conversion to the struct?

       
      I started to code some time basics like HoD()  and then I challenged myself to code other things too as it looks easier to write DoW(..) instead of assign the time to a struct and request a other values as well - feel free to use what you like.
       

      This code calculates the DST automatically for European and US brokers:

      https://www.mql5.com/en/code/27860

      //+------------------------------------------------------------------+
//| Compute the daylight saving time changes in London, UK           |
//| Validated to https://www.timeanddate.com/time/change/uk/london   |
//+------------------------------------------------------------------+
void DST_Europe(int iYear, datetime &dst_start, datetime &dst_end)
  {
   datetime dt1,dt2;
   MqlDateTime st1,st2;
   /* UK DST begins at 01:00 local time on the last Sunday of March
      and ends at 02:00 local time on the last Sunday of October */
   dt1=StringToTime((string)iYear+".03.31 01:00");
   dt2=StringToTime((string)iYear+".10.31 02:00");
   TimeToStruct(dt1,st1);
   TimeToStruct(dt2,st2);
   dst_start=dt1-(st1.day_of_week*86400);
   dst_end  =dt2-(st2.day_of_week*86400);
  }
//+------------------------------------------------------------------+
//| Compute the daylight saving time changes in New York, USA        |
//| Validated to https://www.timeanddate.com/time/change/usa/new-york|
//+------------------------------------------------------------------+
void DST_USA(int iYear, datetime &dst_start, datetime &dst_end)
  {
   datetime dt1,dt2;
   MqlDateTime st1,st2;
   /* US DST begins at 02:00 local time on the second Sunday of March
      and ends at 02:00 local time on the first Sunday of November */
   dt1=StringToTime((string)iYear+".03.14 02:00");
   dt2=StringToTime((string)iYear+".11.07 02:00");
   TimeToStruct(dt1,st1);
   TimeToStruct(dt2,st2);
   dst_start=dt1-(st1.day_of_week*86400);
   dst_end  =dt2-(st2.day_of_week*86400);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnStart()
  {
   datetime dst_start,dst_end;
   dst_start=dst_end=0;

//--- In the European Union, Summer Time begins on the last Sunday in
//--- March and ends on the last Sunday in October.                    |

   Print("========= European Summer Time (DST) =========");
   for(int year=2010; year<=2029; year++)
     {
      DST_Europe(year,dst_start,dst_end);
      Print("DST starts on ",dst_start," and ends on ",dst_end);
     }

//--- In the United States, Summer Time begins on the second Sunday in |
//--- March and ends on the first Sunday in November.                  |

   Print("========= American Summer Time (DST) =========");
   for(int year=2010; year<=2029; year++)
     {
      DST_USA(year,dst_start,dst_end);
      Print("DST starts on ",dst_start," and ends on ",dst_end);
     }
  }
//+------------------------------------------------------------------+

/*
output:
========= European Summer Time (DST) =========
DST starts on 2010.03.28 01:00:00 and ends on 2010.10.31 02:00:00
DST starts on 2011.03.27 01:00:00 and ends on 2011.10.30 02:00:00
DST starts on 2012.03.25 01:00:00 and ends on 2012.10.28 02:00:00
DST starts on 2013.03.31 01:00:00 and ends on 2013.10.27 02:00:00
DST starts on 2014.03.30 01:00:00 and ends on 2014.10.26 02:00:00
DST starts on 2015.03.29 01:00:00 and ends on 2015.10.25 02:00:00
DST starts on 2016.03.27 01:00:00 and ends on 2016.10.30 02:00:00
DST starts on 2017.03.26 01:00:00 and ends on 2017.10.29 02:00:00
DST starts on 2018.03.25 01:00:00 and ends on 2018.10.28 02:00:00
DST starts on 2019.03.31 01:00:00 and ends on 2019.10.27 02:00:00
DST starts on 2020.03.29 01:00:00 and ends on 2020.10.25 02:00:00
DST starts on 2021.03.28 01:00:00 and ends on 2021.10.31 02:00:00
DST starts on 2022.03.27 01:00:00 and ends on 2022.10.30 02:00:00
DST starts on 2023.03.26 01:00:00 and ends on 2023.10.29 02:00:00
DST starts on 2024.03.31 01:00:00 and ends on 2024.10.27 02:00:00
DST starts on 2025.03.30 01:00:00 and ends on 2025.10.26 02:00:00
DST starts on 2026.03.29 01:00:00 and ends on 2026.10.25 02:00:00
DST starts on 2027.03.28 01:00:00 and ends on 2027.10.31 02:00:00
DST starts on 2028.03.26 01:00:00 and ends on 2028.10.29 02:00:00
DST starts on 2029.03.25 01:00:00 and ends on 2029.10.28 02:00:00
========= American Summer Time (DST) =========
DST starts on 2010.03.14 02:00:00 and ends on 2010.11.07 02:00:00
DST starts on 2011.03.13 02:00:00 and ends on 2011.11.06 02:00:00
DST starts on 2012.03.11 02:00:00 and ends on 2012.11.04 02:00:00
DST starts on 2013.03.10 02:00:00 and ends on 2013.11.03 02:00:00
DST starts on 2014.03.09 02:00:00 and ends on 2014.11.02 02:00:00
DST starts on 2015.03.08 02:00:00 and ends on 2015.11.01 02:00:00
DST starts on 2016.03.13 02:00:00 and ends on 2016.11.06 02:00:00
DST starts on 2017.03.12 02:00:00 and ends on 2017.11.05 02:00:00
DST starts on 2018.03.11 02:00:00 and ends on 2018.11.04 02:00:00
DST starts on 2019.03.10 02:00:00 and ends on 2019.11.03 02:00:00
DST starts on 2020.03.08 02:00:00 and ends on 2020.11.01 02:00:00
DST starts on 2021.03.14 02:00:00 and ends on 2021.11.07 02:00:00
DST starts on 2022.03.13 02:00:00 and ends on 2022.11.06 02:00:00
DST starts on 2023.03.12 02:00:00 and ends on 2023.11.05 02:00:00
DST starts on 2024.03.10 02:00:00 and ends on 2024.11.03 02:00:00
DST starts on 2025.03.09 02:00:00 and ends on 2025.11.02 02:00:00
DST starts on 2026.03.08 02:00:00 and ends on 2026.11.01 02:00:00
DST starts on 2027.03.14 02:00:00 and ends on 2027.11.07 02:00:00
DST starts on 2028.03.12 02:00:00 and ends on 2028.11.05 02:00:00
DST starts on 2029.03.11 02:00:00 and ends on 2029.11.04 02:00:00
*/

      The above code was used in Forex Market Hours https://www.mql5.com/en/code/27771 to calculate the day-light saving time changes.

      Similar functions can be constructed for different areas of the world.

      Daylight changes (summer time)
      Daylight changes (summer time)
      • www.mql5.com
      Compute the daylight saving time changes (start/end of the summer time).
      1234
      New comment