Libraries: Dealing with time (2) functions - page 4

[Bretzay]

Carl Schreiber #:

Interesting project. Somehow also seem to have issues running this correctly on a Saturday, unsure how to resolve. Can anyone provide instructions for the proper fix and secondly

Hello Carl, first of all, thanks for your library and detailed guide on how to use time on MQL5.

I allow myself to answer to your question directed to Flying Dutchman because I think I have the same issue. (quite of)

To give you as much information as I can, I am using FTMO Demo server as my strategy tester server.
FTMO Demo server seems to be as of today, 25/04/24, on UTC  +3, and if I try to start backtesting on the first of March, it seems to be in UTC  +2 and on the 10th of March, it is UTC  +3 because of NY change of timezone.
If one was to start the strategy tester on the first of April of this year, the bot would stop instantly, if one was to start it on the prior Friday of this date (29/03), it would run without issues, or it seems like it.
I tried on multiple Monday, and the issue was there everytimes. The issue seems to happen on Sunday, and Monday when I start the strategy tester on them. And the error I get is that it stopped in the initialisation with the alert "setBrokerOffset failed".

Here are the snippets I used from the library :

int OnInit()
   {  
      bool isTimeSet = setBokerOffset();
      if(!isTimeSet)
         {
         Alert("setBokerOffset failed");
         return(INIT_FAILED);
         }
         // Some other unrelated code here...
    }
void OnTick()
{  
   // ===== Time check =====
   checkTimeOffset(TimeCurrent());
   datetime gmtTime = TimeCurrent() + OffsetBroker.actOffset;
   // The rest of my code here, with a time check using gmtTime instead of TimeCurrent().
}

From my understanding of your explanation, that is enough to make the library to work on any expert advisor. 

I may have reached another issue, or maybe just me that do not understand exactly how the script works, it is not correlated with the Sunday/Monday issue but with the DST changes.

As weird as it looks like, starting on 11th of March, which is as you guessed it, the Monday right after NY DST change, my broker seems to already get in UTC  +3 (I check a news on Trading view at 12:30 UTC, and compare it to my visual backtest where it says 15:30), so it has already made the change in server time to New York. The strange part is that the OffsetBroker.actOffset is giving me -4, which means UTC+4, which is not what my broker gives, so it switches of one hour too much on the week of NY Sum EU win. 
The previous week, everything was fine and FTMO was providing with UTC +2, and it was calculated correctly from what I've seen. And right after the 30th of March, so after the European DST, it switches back to UTC +3, which makes it quite weird to me.

I'm not sure if it's a problem in the code itself, or if I just did not understand what you wrote about the NYsumEUwin, even after reading it 4 times, but I think that may be useful to notice it here, so I can understand what's happening.

[Carl Schreiber]

Thanks for the information, I will look into this at the weekend.

[amrali]

Carl Schreiber #:
Thanks for the information, I will look into this at the weekend.

The cause of this problem is the faulty BoW() macro.

[Carl Schreiber]

amrali #:
The cause of this problem is the faulty BoW() macro.

No, I already replaced it with a corrected version.

[Carl Schreiber]

The problem is the MQL5 function CopyTime().

This:

    datetime arrTme[],                                          // array to copy time
             tC = TimeCurrent(),                                // Mo. Apr 1st 2024 <= set in Editor => Tools => Options => Debug and run in the debugger
             BegWk = BoW(tC),                                   // Su. Mar. 31 2024 = correct!
...
    int b = CopyTime("EURUSD",PERIOD_H1,BegWk-28*3600,tC,arrTme);

does not copy the open time of the actual bar which is tC = TimeCurrent(). What ever I tried the last copied time of the h1 bars is Fr. Mar. 29 2024 22:00, the bar of the given time is missing :(

I know MQL5 does not like to look into the future but failing with the present is new to me - or is this a feature?

I am working with MQ demo account on EurUsd.

[amrali]

Carl Schreiber #:
CopyTime

That is because The last bar of TC is uncompleted bar, that is normal behavior.

Instead, use:

datetime Sun02pm = BegWk+14*3600;  // Forex open time on brokers in San Francisco (GMT-8)
datetime Mon10am = BegWk+34*3600;  // Forex open time on brokers in New Zealand (GMT+12)

int b = CopyTime("EURUSD", PERIOD_H1, Sun02pm, Mon10am, arrTme);

or,

int b = CopyTime("EURUSD", PERIOD_H1, BegWk+34*3600, 20, arrTme);

Also, you still have a problem on Saturdays, because BoW is faulty().

Fixed version see #18

[Carl Schreiber]

amrali #:
Also, you still have a problem on Saturdays, because BoW is faulty().

Not to my understanding.

If I start on Saturday 2024.03.30 00:00:00 the beginning of the week is the previous Sunday 00:00 =>

datetime tC     = TimeCurret(),   // D'2024.03.30 00:00:00' Saturday
         BegWk  = BoW(tC),        // D'2024.03.24 00:00:00' prev. Sun 00:00
...

This is important as the change of DST happens after Su 00:00.

BUT timestamps in the future do not woth with CopyTime() and other CopyXxxx():

I set the beginning of debugging at D'2024.04.01 00:00:00' Monday:

datetime tC     = TimeCurret(),   // D'2024.04.01 00:00:00' Monday
         BegWk  = BoW(tC),        // D'2024.03.31 00:00:00' Sunday (yesterday)
...

int bb = CopyTime("EURUSD",PERIOD_H1,BegWk-48*3600,tC+3600,arrTme);

arrTme now runs from:

arrTme[0]   = D'2024.03.29 00:00:00'
...
arrTme[22] = D'2024.03.29 22:00:00'

despite the 'highest' time should be tC+3600 = D'2024.04.01 01:00:00'

That means even if the market is already opened at Mon. 00:00 I am trapped as CopyTime() won't fill the array with this timestamp :(

and I cannot get and detect the time gap e.g. from Fr.22:00 to Su. 22:00.

If I start the debugging at Tuesday 2024.04.02 00:00:00 CopyTime is filled by:

arrTme[0]   = D'2024.03.29 00:00:00'
...
arrTme[46] = D'2024.04.01 23:00:00'

See, the date (yyyy.mm.dd 00:00:00) when the debugger/tester starts 'lies in the future' and so it won't be part of the array :(

[amrali]

Forum on trading, automated trading systems and testing trading strategies

Libraries: Dealing with time (2) functions

Carl Schreiber, 2024.04.27 21:42

Not to my understanding.

If I start on Saturday 2024.03.30 00:00:00 the beginning of the week is the previous Sunday 00:00 =>

datetime tC     = TimeCurret(),   // D'2024.03.30 00:00:00' Saturday
         BegWk  = BoW(tC),        // D'2024.03.24 00:00:00' prev. Sun 00:00
...

Check this:

#define  BoW(t) ((t)-((t-172800)%604800 - 86400))   // Begin of Week.. Su 00:00:00: 604800=168h=7*24; 172800=35.5h; 86400=24h (from DealingWithTime.mqh)
#define  BoW_correct(t) ((t)-((t)+345600)%604800)   // my fixed version

void OnStart()
  {
   datetime t = D'2024.03.30 00:00:00';  // Saturday

   Print("BoW: ", BoW(t));

   Print("BoW_correct: ", BoW_correct(t));
  }

// BoW: 2024.03.31 00:00:00
// BoW_correct: 2024.03.24 00:00:00

Regarding errors with CopyTime(), you can replace CopyTime() to iBarShift().

Please check my lib here 

[Carl Schreiber]

amrali #:

Check this:

Regarding errors with CopyTime(), you can replace CopyTime() to iBarShift().

Please check my lib here 

1.  At home I alrteady am using your corrected version and I was convinced I had uploaded it - I must have mixed up something, I change it as soon as I have found a solution for Monday.
2. I don't see how iBarSchift (int iB = iBarShift(_Symbol, PERIOD_H1, tC, false);)  can help. If I call it with tC=TimeCurrent() (e.g. =  D'2024.04.01 00:00:00' Monday) I get 0 which is the 'oldest' in the debugger starte at 2024.04.01.
   
3. I am looking for the time gap over the weekend. I want to detect not only the the weekend but as well the open time of the first bar of the new week as this determines the open time of the last bar of the week and therefore the last seconds of this bar and the FX session (+ 3600) e.g. to close positions in time ...
4. As I don't get this open time of the new bar in OnInit() where setBokerOffset() is called I have to calculate it: the time of last bar +/- the change of DST of the actual weekend.
   

[amrali]

Carl Schreiber #:
int iB = iBarShift(_Symbol, PERIOD_H1, tC, false);

datetime FstBarWk = 0;

int iB = iBarShift(_Symbol, PERIOD_H1, BoW(tC), false);
if (iB > 0)
{
   FstBarWk = iTime(_Symbol, PERIOD_H1, (iB - 1));
}