Simulating time in the MT4 tester and whether it is necessary to cast datetime to long

[Vladislav Boyko]

Comments that do not relate to the "Stop Trading Today when Loss or Consecutive Loss", have been moved into this topic.

[Ryan L Johnson]

anuj71:

I am trying to add Loss control to my EA...

[Am I] doing [it] correct? 

You appear to have the right idea, so run your EA through the Tester to confirm it. By the way, the Tester always uses GMT.

Best practice is to typecast time to a ulong data type variable prior to using it in math/comparisons/evaluations. I don't see your variable declarations, so...

[Ryan L Johnson]

Ryan L Johnson #:

You appear to have the right idea, so run your EA through the Tester to confirm it. By the way, the Tester always uses GMT.

Best practice is to typecast time to a ulong data type variable prior to using it in math/comparisons/evaluations. I don't see your variable declarations, so...

Edit: TimeLocal() returns GMT in the Tester. TimeCurrent() returns GMT+/- per the historic data timestamps during bactesting.

[Vladislav Boyko]

Ryan L Johnson #:
By the way, the Tester always uses GMT.

Edit: TimeLocal() returns GMT in the Tester. TimeCurrent() returns GMT+/- per the historic data timestamps during bactesting.

Please clarify what exactly you mean. It would be helpful to provide code as an example demonstrating what you're saying.

https://docs.mql4.com/dateandtime/timecurrent

During testing in the Strategy Tester, TimeCurrent() is simulated according to historical data.

https://docs.mql4.com/dateandtime/timelocal

During testing in the Strategy Tester, TimeLocal() is always equal to TimeCurrent() simulated server time.

[Vladislav Boyko]

Ryan L Johnson #:
Best practice is to typecast time to a ulong data type variable prior to using it in math/comparisons/evaluations.

Please prove this with a benchmark or cite the source of the information.

[Ryan L Johnson]

Vladislav Boyko #:

Please clarify what exactly you mean. It would be helpful to provide code as an example demonstrating what you're saying.

"Simulation of Time in the Tester

When testing, the time is simulated according to the historical data. TimeLocal() local time is always equal to TimeCurrent() server time. In turn, the server time is always equal to the time corresponding to the GMT - TimeGMT(). This way, all of these functions display the same time during testing.

The absence of the difference between GMT, local and server time in the tester is provided deliberately in case connection to the server is lost. The test results should always be the same, regardless of whether or not there is a connection. Information about the server time is not stored locally, and is taken from the server."

[Ryan L Johnson]

Vladislav Boyko #:
Please prove this with a benchmark or cite the source of the information.

The following documentation states that a long can be typecast to a datetime. I know that the inverse is true based on my experience, at least for ulongs. I don't know whether that information precedes the advent of the ulong data type.

Unfortunately, I'm unable to find the Forum post wherein another developer recommended that typecasting to me several years ago.

[Alain Verleyen]

Ryan L Johnson #:

"Simulation of Time in the Tester

When testing, the time is simulated according to the historical data. TimeLocal() local time is always equal to TimeCurrent() server time. In turn, the server time is always equal to the time corresponding to the GMT - TimeGMT(). This way, all of these functions display the same time during testing.

The absence of the difference between GMT, local and server time in the tester is provided deliberately in case connection to the server is lost. The test results should always be the same, regardless of whether or not there is a connection. Information about the server time is not stored locally, and is taken from the server."

Please read it again. That doesn't mean "the Tester always uses GMT." as you stated. It's the reverse, in the Tester ALL time are SERVER (data) TIME.

[Alain Verleyen]

Ryan L Johnson #:

The following documentation states that a long can be typecast to a datetime. I know that the inverse is true based on my experience, at least for ulongs. I don't know whether that information precedes the advent of the ulong data type.

Unfortunately, I'm unable to find the Forum post wherein another developer recommended that typecasting to me several years ago.

Being able to typecast a datetime to long doesn't mean it becomes a "Best practice". And in the current topic it's useless and irrelevant.

Someone saying something on the forum doesn't mean it's exact and correct information.

[Vladislav Boyko]

Ryan L Johnson #:
When testing, the time is simulated according to the historical data. TimeLocal() local time is always equal to TimeCurrent() server time. In turn, the server time is always equal to the time corresponding to the GMT - TimeGMT(). This way, all of these functions display the same time during testing.

I could be wrong, but my understanding is that TimeCurrent() is simulated based on historical data, while TimeLocal() and TimeGMT() simply return TimeCurrent().