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

[Luandre Ezra]

Hi @Carl Schreiber,

Great article you've made, it helps a lot. Just want to tell you what I found after using your code.

I'm using eightcap broker and tried to use a simple script to show what the actual time in the respective country and found that Tokyo time is 1 hour late from the actual time. Here's the script that I use,

void OnStart()
  {
   bool isTimeSet = setBokerOffset();
   if(!isTimeSet)
     {
      Alert("setBokerOffset failed");
      return;
     }

   Alert("+++++++++++++++");
   checkTimeOffset(TimeCurrent());
   datetime tGMT  = TimeCurrent() + OffsetBroker.actOffset;    // GMT
   datetime tNY   = tGMT - (NYShift+DST_USD);                  // time in New York
   datetime tLon  = tGMT - (LondonShift+DST_EUR);              // time in London
   datetime tSyd  = tGMT - (SidneyShift+DST_AUD);              // time in Sidney
   datetime tMosc = tGMT - (MoskwaShift+DST_RUS);              // time in Moscow
   datetime tTok  = tGMT - (TokyoShift);                       // time in Tokyo - no DST

   Alert("time NY: ", tNY);
   Alert("time Lon: ", tLon);
   Alert("time Syd: ", tSyd);
   Alert("time Tok: ", tTok);
  }

the code is copy and paste from the article and I just return the value from it. I don't think that the problem from how I used the code because the other session is correct.

[Carl Schreiber]

Luandre Ezra #:

Hi @Carl Schreiber,

Great article you've made, it helps a lot. Just want to tell you what I found after using your code.

I'm using eightcap broker and tried to use a simple script to show what the actual time in the respective country and found that Tokyo time is 1 hour late from the actual time. Here's the script that I use,

the code is copy and paste from the article and I just return the value from it. I don't think that the problem from how I used the code because the other session is correct.

From GMT (=UTC) the time diff is 0900 hours (from https://www.worldtimeserver.com/current_time_in_JP.aspx?city=Tokyo)

= 9*-3600=32400 seconds:

And this is is set:

#define TokyoShift   -32400                           // always 9h

[Luandre Ezra]

Carl Schreiber #:

From GMT (=UTC) the time diff is 0900 hours (from https://www.worldtimeserver.com/current_time_in_JP.aspx?city=Tokyo)

= 9*-3600=32400 seconds:

And this is is set:

Mistake that I made. It's not tokyo but sydney.

[Carl Schreiber]

It could be that the calculation of the Australian DST switch is faulty - I'll look into it, thanks.

[Alain Verleyen]

Australian First Sunday of October at 02:00 to First Sunday of April at 02:00

Australian DST 2010 start 2010.10.03 - end 2010.04.04
Australian DST 2011 start 2011.10.02 - end 2011.04.03
Australian DST 2012 start 2012.10.07 - end 2012.04.01
Australian DST 2013 start 2013.10.06 - end 2013.04.07
Australian DST 2014 start 2014.10.05 - end 2014.04.06
Australian DST 2015 start 2015.10.04 - end 2015.04.05
Australian DST 2016 start 2016.10.02 - end 2016.04.03
Australian DST 2017 start 2017.10.01 - end 2017.04.02
Australian DST 2018 start 2018.10.07 - end 2018.04.01
Australian DST 2019 start 2019.10.06 - end 2019.04.07
Australian DST 2020 start 2020.10.04 - end 2020.04.05
Australian DST 2021 start 2021.10.03 - end 2021.04.04
Australian DST 2022 start 2022.10.02 - end 2022.04.03
Australian DST 2023 start 2023.10.01 - end 2023.04.02
Australian DST 2024 start 2024.10.06 - end 2024.04.07
Australian DST 2025 start 2025.10.05 - end 2025.04.06
Australian DST 2026 start 2026.10.04 - end 2026.04.05
Australian DST 2027 start 2027.10.03 - end 2027.04.04
Australian DST 2028 start 2028.10.01 - end 2028.04.02
Australian DST 2029 start 2029.10.07 - end 2029.04.01

[Carl Schreiber]

I found the problem: I missed a check:

At the beginning of the function void checkTimeOffset(datetime tB) I placed a check:

if(tB < nxtSwitch_USD && tB < nxtSwitch_EUR)
      return;  

And this I had to change to:

if(tB < nxtSwitch_USD && tB < nxtSwitch_EUR && tB < nxtSwitch_AUD)
      return;  

I'll update it ...

[Luandre Ezra]

Carl Schreiber #:

I found the problem: I missed a check:

At the beginning of the function void checkTimeOffset(datetime tB) I placed a check:

And this I had to change to:

I'll update it ...

Hi Carl, Unfortunately changing the corresponding code doesn't fix the issue. I also found that Moscow time is different from universal time.

[Carl Schreiber]

The version of DealingWithTime.mqh v. 1.01 of the article "Dealing with Time (Part 2): The Functions" ( https://www.mql5.com/en/articles/9929 ) no longer worked because MQ changed the behaviour of the CopyTime() function some time after this article was published. Now this function no longer returns future time values if they are greater than TimeCurrent() specified for the start_time and/or stop_time parameters. Instead, the opening time of the last, current bar is returned as the largest possible value.

As the end of the FX session was determined in this way in order to determine the offset of the broker time, among other things, this now leads to incorrect values!

This calculation was changed in version 2.03. This new version is now available in the CodeBase here: https://www.mql5.com/en/code/45287.

The calculation of the time changeover has also been completely changed so that the complicated times of the time changeover from Sydney (Australia) back to the 1970s are now also covered.

Enclosed is also the table DST 1975 - 2030.xlsx as a zip file with all time changes since the 70s, so that everyone can check the correct functioning of the formulas, here is an example series of the table:

01.01.1982 is winter time in the USA (DST==0) and the next changeover is on 25.04.1982, the last (25th of the month) Sunday in April (4). The table is already sorted according to the geographical time zone (column A), then according to the time zone of the year (column L, spr=spring, aut=autumn,) and finally according to the query date (column C). The table can be created automatically by the included EA (a script cannot be run in debug mode). Test_DST 2.mq5 if you run it in debug mode and copy the lines of the journal log in the debugger and paste them into a spreadsheet programme; the cell separator would be the space character.

Also, there is now a new, simple function SecTillClose(), which gives you the remaining time in seconds (the time currency of MQ) until the forex market is closed - without CopyTime(). This is interesting for those who want to close their positions before the weekend or do not want to open a new position in a defined period before the weekend.

The included indicator DealingWithTime_TestIndi.mq5 shows as a comment on the chart not only the summer/winter time of Europe, the USA and Australia (Sydney), but also the current time and the time difference of various cities. Here you will also find a table with different local times for major cities, for example for comparison with: https://www.timeanddate.com/worldclock/. You can therefore check the values at any time. This indicator also shows how these values are determined and used (what is subtracted from or added to what) so that it is easier to use it yourself - copy and paste, the fastest form of programming.

The last two lines also show the last second of the current FX session and the remaining time in hours (easier to judge) and seconds. If the FX session in New York is closed at 17:00 local time on Fridays, there is no valid bar with an opening time at 17:00 New York time. Therefore, 1 second is subtracted in this function to get the last valid opening time of the last bar in broker time. However, some brokers end their FX session a few minutes earlier by no longer providing prices and no longer accepting trade orders.

[Carl Schreiber]

The version of DealingWithTime.mqh v. 1.01 of the article Dealing with Time (Part 2): The Functions ( https://www.mql5.com/en/articles/9929 ) stopped working because MQ changed the behavior of the CopyTime() function some Time after publication of this article. Now this function no longer returns future time values if they are greater than TimeCurrent() specified for the start_time and/or stop_time parameters. Instead, the open time of the last, current bar is returned as the largest possible value.

Since the end of the FX session was determined in this way in order to determine the broker time offset, this now leads to incorrect values!

This calculation was changed in version 2.03. This version is now available in the CodeBase here: https://www.mql5.com/en/code/45287 .

But also the calculation of the time change was completely changed, so that now the complicated times of the time change from Sydney (Australia) back to the 70s are covered.

Also attached is the table DST 1975 - 2030.xlsx as a zip file with all the time changes since the 70's so everyone can check the correct working of the formulas, here is an example series of the table:

January 1, 1982 is standard time in the USA (DST==0) and the next changeover will be on April 25, 1982, the last (25th of the month) Sunday in April (4). The table is already sorted by geographic time zone (column A), then by time zone of the year (column L, spr=spring, aut=autumn,) and finally by query date (column C). The table can be created automatically by the included EA (a script cannot be run in debug mode). Test_DST 2.mq5 if you run it in debug mode and copy the lines of the journal log in the debugger and paste them into a spreadsheet; The cell separator would be the space.

Also, there is now a new, simple function SecTillClose() , which gives you the remaining time in seconds (the time currency of MQ) until the forex market is closed - without CopyTime() . This is interesting for those who want to close their positions before the weekend or do not want to open a new position in a defined period before the weekend.

The included indicator DealingWithTime_TestIndi.mq5, as a comment on the chart, shows not only daylight saving time in Europe, the USA and Australia (Sydney), but also the current time and the time difference of various cities. Here you can find a table with different local times of major cities for comparison: https://www.timeanddate.com/worldclock/ . You can therefore check the values at any time. This indicator also shows how these values are determined and used (what is subtracted or added from what), making it easier to use yourself - copy and paste, the fastest form of programming.

The last two lines also show the last second of the current FX session and the remaining time in hours (which is easier to judge) and in seconds. In New York, when the FX session closes at 5:00 pm local time on a Friday, there is no valid bar open at 5:00 pm New York time. Therefore, in this function, 1 second is subtracted to get the last valid open time of the last bar in the broker time. However, some brokers end their FX session a few minutes early by no longer providing prices and no longer accepting trade orders.

[Carl Schreiber]

The version of DealingWithTime.mqh v. 1.01 from the article "Managing the Timetable (Part 2): Functions" ( https://www.mql5.com/en/articles/9929 ) stopped working because MetaQuotes changed the behaviour of CopyTime() and now they no longer work some time after the publication of this article. Now this function no longer returns future time values if they are greater than the TimeCurrent() specified for the start_time and/or stop_time parameters. Instead, the open time of the last current bar is returned as the largest possible value.

Since the end of the FX session was determined in this way to determine the broker's time offset, this now leads to incorrect values!

This calculation was changed in version 2.03. This version is now available on CodeBase here: https://www.mql5.com/en/code/45287.

But also the time change calculation was completely changed, so that the complicated time change times from Sydney (Australia) to the 1970s are now covered.

Also attached is the table DST 1975 - 2030.xlsx as a zip file with all time changes since the 1970s so that everyone can verify the correct working of the formulas, here are a number of examples of the table:

1 January 1982 is standard time in the USA (DST==0) and the next change will be 25 April 1982, the last (25th of the month) Sunday in April (4). The table is already sorted by geographical time zone (column A), then by time zone of the year (column L, spr=spring, aut=autumn) and finally by date of query (column C). The table can be created automatically by the included EA (a script cannot be run in debug mode). Test_DST 2.mq5 if you run it in debug mode and copy the journal lines into the debugger and paste them into a spreadsheet; The cell separator would be the space.

In addition, there is now a simple new function, SecTillClose(), which gives you the time remaining in seconds (the MetaQuotes time currency) until the forex market closes, without CopyTime(). This is interesting for those who want to close their positions before the weekend or do not want to open a new position in a defined period before the weekend.

The included indicator DealingWithTime_TestIndi.mq5, as a comment on the chart, shows not only the daylight saving time in Europe, USA and Australia (Sydney), but also the current time and the time difference of various cities. Here you can find a table with different local times of the main cities for comparison: https://www.timeanddate.com/worldclock/. You can therefore check the values at any time. This indicator also shows how these values are determined and used (what you subtract or add), which makes it easy to use: copy and paste, the fastest way of programming.

The last two lines also show the last second of the current FX session and the time remaining in hours (which is easier to judge) and seconds. In New York, when the FX session closes at 5:00 p.m. local time on a Friday, there is no valid bar open at 5:00 p.m. New York time. Therefore, in this function, 1 second is subtracted to obtain the last valid open time of the last bar in the broker's time. However, some brokers end their FX session a few minutes earlier and no longer provide prices or accept trade orders.