Centralizing agnostic time differnces between brokers

New comment
 

I started out simply wanting to avoid NonFarm news and make sure in tester orders were not triggered, first Friday of the month, relative hour news happens.

The effort started out as ...

   if(TimeDayOfWeek(TimeCurrent())==5 && TimeDay(TimeCurrent())<=7 && TimeHour(TimeCurrent()) == 15)
   {
      Print("NFP");return;
   }


It  became obvious this can't work on multiple brokers who's server time base is not the same as the discrete references shown above, which is a poor approach at best.

Ideally, I'd like to avoid NFP 30 minutes before until 60 minutes after, which the above can't do, regardless of broker's server base time worse yet.


Is there a "best practice" on how to create an agnostic time reference that can solve the time comparisons across multiple server base times?

Do I convert all back to GMT as a consistency and will that handle brokers with or without DST checked on in the server?

I'm sure there's probably more than one acceptable solution, but in searching the forums I didn't find any consistent examples.  Many of the EAs apply their own specific solution, many times having users input a GMT offset in rather inconsistent if not possibly misleading manners.  I'd like to be able to neutralize the difference without forcing the user to assume a manual config entry in the set file, etc., if possible.  I don't work with Mt4's time function abstractions often, so I'm looking for suggestions on the best approach please, to make sure both tester and live can handle different brokers time bases to avoid specific news events.

Thanks for any suggestions or examples.

  
if ((TimeGMT() > StrToTime("2015.09.04 12:30")-PERIOD_M30*60) && 
    (TimeGMT() < StrToTime("2015.09.04 12:30")+PERIOD_H1*60)) {
   Print("NFP");return;   
}
for live
 

Thanks Ted.

The solution needs to at least find the centralized time of NFP occurring on the "first Friday" of every month.

This "assumes" NFP actually occurred on the first Friday of the month, which some times it does not.

Perhaps most accurately the solution would seek a published calender because NFP is sometimes deviated around holidays etc.

Making the solution dependent on reading a published calendar event, means historical past NFP events must be retrieved, stored and recalled specifically.

The time base of the particular broker is likely accounted for by such an indicator in "some manner", so long as the values recalled in iCustom() can be translated.

Finding a solution that works reliably in all cases across all brokers, accounting for both live and back test, is the real issue I'm having.

The problem is relatively complex which is why I think there are few if any examples that account for automating a moving target like this.


I'm fairly sure the solution is going to end up dependent on a published calendar indicator that sustains a historical back file for back testing and also reads real-time when running live.

In both cases the consideration of a given broker's time base has to be accounted for by the method and whether or not the broker in question is tracking DST.

New comment