TimeCurrent() vs. TimeLocal()
Yes my broker just changed the server time by an hour as well. (Probably the same broker). This makes back-testing time related strategies very dubious as you would have to code in the date the switch-over occurred :-(
Since trades are logged by server time it makes life difficult if you save other stuff by local time. I wouldn't do it myself - just stick with server time.
Yes my broker just changed the server time by an hour as well. (Probably the same broker). This makes back-testing time related strategies very dubious as you would have to code in the date the switch-over occurred :-(
Since trades are logged by server time it makes life difficult if you save other stuff by local time. I wouldn't do it myself - just stick with server time.
Thanks for the reply. Yes, I agree - it really screws up back testing. I feel sorry for the people who get hold of any back data from the broker over that period in the future and don't realize that there was a time zone shift in the middle of it ...
There doesn't seem to be a function to look up the time zone of the broker. That means that theoretically they could change the time zone at any point and the code would be none the wiser. The issue would be solved if there were such a function to start calculations from.
As I figure it, there is about as much chance that the a broker will up and change their time zone (again) without being noticed as there is that the clock on the client computer would randomly change without being noticed. And in either case, I'm sure the broker would not accept any liability. So both TimeCurrent() and TimeLocal() are still equally as unreliable. I guess it would be possible to use a third party to check the current time - but then there are reliability issues with that again.
I log all trades and events with full server AND client date and time - so that equals itself out. What I find confusing is that now we're GMT+2 that throws off the 24h clock in my head, because the 24h clock is ALREADY offset by "2h" from "normal" time, and then you have to offset that again by 2h for broker time. I'm sure I'm not the only one who's brain feels bruised every time they try and work out the actual time on historical charts now!
I guess the issue is solved by the use of Time[] to get the indexed time for previous bars. As far as I'm aware there is no method to get indexed time by local time, because I assume that is not saved and attached to bar data by MT4? So anyone who wants to get indexed time has to use server time, which makes it simpler to use server time for everything else I guess, and so people just end up using server time for everything...
I think I'll take your advice and just stick to server time. Even though it will cause my brain to dribble out through my ears.
clerin6:
I think I'll take your advice and just stick to server time. Even though it will cause my brain to dribble out through my ears.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Does anyone know of any reason NOT to use TimeLocal() when filtering trade signals?
My broker just changed their time zone (now GMT+n), and I live in the GMT time zone. Rather than me making adjustments for their new time zone by adding an offset to the TimeCurrent(), it seems easier just to use TimeLocal() with no offset – but alarm bells are ringing in the back of my head, and I’m not sure why ….
Other than TimeLocal() being reliant on my computer time (which could go wrong and, I could not blame my broker), is there any other known good reason for not using TimeLocal() that I am missing …. ?
Thanks.