Any rookie question, so as not to clutter up the forum. Professionals, don't pass by. Nowhere without you - 6. - page 557
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
I'm not going to look up where it says that time is generated in the tester, you know that yourself. But in the help it specifically says that
Whereas it does not say anything specific about StringToTime().
The only thing to take into account is time on the tester (of the DC server). And so when testing, you need to have a history of the same type of account on which this owls will work.
Alexey, I don't have any question about the function StrToTime() The question is different. It will return the right time, but 21 hours today is 22 hours before March 9. That's why I have written functions that correctly take into account DST of broker.
Without it if an Expert Advisor works according to some time schedule it is impossible to test. Everything shifts by one hour. There are no problems in real trading but there are problems with the tester. I have been asking developers to enable the function that calculates time shifts for a long time. They have implemented TimeGMT(), but it is tied to the local time and computer's time zone. And you have to have a brakker shift. And their DST is different from ours. Brokers shift first Sunday in November second Sunday in March and Russia (if it will be...) last Sunday in October last Sunday in March. So you have to write your own functions for now.
I have no objections to the principles, but the man wants to run the Expert Advisor in the tester, so your options do not suit him.
Use my variant, it will work both in real and in tester, but until they did not make a function to automatically take into account daylight saving time, define the time of transition to this year like
From March 2013 to November 2014 will work and test correctly. Set the shift according to your brokerOK. Thank you. I will let you know the outcome.
It is necessary to check on the charts < h4 the time of the last bar of the current Friday and the Friday before March 8. If these times coincide, the hrd value is constant and does not depend on winter-summer time change and then everything is simple and will work correctly during testing irrespective of winter-summer time change
but if these two times are different (differ by 1 hour) then as I wrote before.
We should check on the M1 chart the time of the last bar of the current Friday and the Friday before March 8. If these times coincide, the hrd value is constant and does not depend on the transition to winter-summer time, and then everything is simple and will work correctly during testing regardless of the winter-summer transition
but if these two times are different (differ by 1 hour) then as I wrote before.
Why is there a 15 minute time in the code, i.e. you want to say that 15 minutes before the end of the session the portfolio rebalancing starts? I certainly noticed such moments on mt4 at fresch and I saw good levels on some currency pairs.
For example, I want to close trades even 1 minute before the end of the session, because when an order is left for the weekend, it happens that on Monday the opening price can jump by 100, or 200, or even more pips.
I haven't tested it yet. I'll test it later today.
Well this should not work in the tester.
The functions are based on current time, and what I wrote above will work because TimeCurrent() and TimeDayOfWeek() work correctly. You only need to add function for switching to summer and winter time, i.e. parameter hrd. Switching usually takes place according to American DST time (first Sunday of November second Sunday of March), but some brokers do not make the switch, so you should use your
If my broker is in Russia and I am in Ukraine, then there is no daylight saving time or winter time change, then it turns out that there is no daylight saving time changeover at my broker, but only the local time?
There is no need to compare the broker's and your local time. No matter how much you move your watch, the end time of the broker's session on the chart will not change. The question was about the transition to the summer time quotes of brokers on March 8-9, and some brokers do it, and some do not.
I wrote - look at the charts for the last bar times before and after March 9, if the same then use the last simple option, if they differ by an hour then the more complex one.
Guys, hats off :) Both DayOfWeek() TimeDayOfWeek(datetimedate) and similar formulas will work correctly in the tester. Tester models time of tick which it processes, that's why in DayOfWeek() which takes last known server time also works. More correctly of course use TimeDayOfWeek(dt1)
In general everything is correct, the only thing left is to take into account the time of transition of broker to winter-summer time, if there is one, as I wrote above.