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
Better read the documentation again:
You could say that it is most accurate during the initial stages of the OnTick() event, but it becomes more stale the longer you are execution.
If your OnTick() is so long then update your data.
Anyway how is it related to the initial calculation ?
Besides, @whroeder1 calculations have to be valid not matter where it runs be it in OnInit, OnTimer, OnStart, OnChartEvent, etc.
So what ?
If your OnTick() is so long then update your data.
Anyway how is it related to the initial calculation ?
So what ?
Lets say that exactly at 22:59:58 local time and 23:59:58 server time a new bid tick price is sent out by the server to the clients. However, due to network delays, it only arrives 15 seconds later.
So, as the OnTick() is triggered, the local time is now 23:00:13, but server time is reported as 23:59:58.
However, due to very bad code in the processing, your code takes another 3 seconds before it reaches the code that handles this calculation. By then local time is 23:00:16.
So the calculation is now working with the server time of 23:59:58 (still has not changed as no new ticks have arrived) and a local time of 23:00:16.
@whroeder1's calculation handles both the network jitter (irregularity of packet arrivals) as well as processing delay or even local clock being improperly setup or out of sync with NTP server.
One way that MetaTrader could have corrected this issue, was to have created a local “internal” clock that would be adjusted and corrected to be in sync with the server clock, much like a NTP service.
Since they did not do that, one could also create the code to do just that, and in this way have an internal continuous clock representing the server time.
However, @whroeder1's solution of rounding, I believe is more than sufficient to work around most of these problems (no matter where in the code it is used), without the need to create our own internal server clock.
I hope my explanation is sufficiently clear now!
Lets say that exactly at 22:59:58 local time and 23:59:58 server time a new bid tick price is sent out by the server to the clients. However, due to network delays, it only arrives 15 seconds later.
So, as the OnTick() is triggered, the local time is now 23:00:13, but server time is reported as 23:59:58.
However, due to very bad code in the processing, your code takes another 3 seconds before it reaches the code that handles this calculation. By then local time is 23:00:16.
So the calculation is now working with the server time of 23:59:58 (still has not changed as no new ticks have arrived) and a local time of 23:00:16.
@whroeder1's calculation handles both the network jitter (irregularity of packet arrivals) as well as processing delay or even local clock being improperly setup or out of sync with NTP server.
One way that MetaTrader could have corrected this issue, was to have created a local “internal” clock that would be adjusted and corrected to be in sync with the server clock, much like a NTP service.
Since they did not do that, one could also create the code to do just that, and in this way have an internal continuous clock representing the server time.
However, @whroeder1's solution of rounding, I believe is more than sufficient to work around that most of these problems (no matter where in the code it is used), without the need to create our own internal server clock.I really don't know why you are arguing.
EDIT: I will not make a study to measure all implied time and prove that your jitter is statistically negligible compared to out of sync computers time. I already know it is, you will always find case where it is not.
EDIT2: I wish you a good night.
I really don't know why you are arguing.
Hey guys,
Thanks for taking the time to explain to me the issue of having two separate clock times. You would think that the platform would take care of that automatically and sync the server time to the pc clock and then update the platform as synchronized times... but now I understand the issue, and I like whroeders implementation of the rounding to compensate. I'm glad I got to participate in this discussion, and I've got some libraries to go fix :-p
You are welcome, but just a wait a little longer because @Alain Verleyen suggests that there might be an alternative to the use of TimeCurrent(). I don't know what it is, but maybe it could offer a better solution!
To be honest, this formula takes so little resources to implement in the initialization of time off-set that I don't even want to take the slightest risk of not using it. I was wrong and I made my initial statement on a bad assumption.
Sorry, bad English.
I mean continue a discussion when there is nothing to discuss. Also there is nothing to agree or disagree.
I can imagine you want to know what to use instead of TimeCurrent(), my answer is : "Please show us your code if you need coding help".
I can imagine you want to know what to use instead of TimeCurrent(), my answer is : "Please show us your code if you need coding help".
I sometimes don't understand you! You can't mix "humor" and "serious" together and hope that reader is able to distinguish between the two without being offended. You have to be clear!
You yourself, just stated that I mixed definitions mid post and that was causing confusion. So I say the same, you can't just state "I already said TimeCurrent() should not be used for the envisaged calculation" in the middle of a serious post and hope that we take just take that part as humor.
Please, that was not very nice of you to do, because it is misleading. So please I ask again in order to get a very clear and serious answer!
Is there or is there not an alternative to the use of TimeCurrent()?
EDIT: If you say, creating your own internal synchronised, continuous, server clock then that, I have already stated that. If on the other-hand I have caught you out on a lie, then please be man enough to admit it. There will be no ill feelings.