time in the terminal at the championships - page 2
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 would like to hear a comment from the organisers of the championship.
Thank you.
...it's not the only one we won't get an answer to - that's the policy . he who pays the piper calls the tune.
I wonder how the response to the answer "the server will switch to winter time" or "the server will not switch to winter time" will depend on this?
Just curious about the software implementation associated with this knowledge.
With daylight saving time support.
Well, what's the point of hiding information about the time of the championship server and the presence/absence of daylight saving time?
For example, the championship server is not up and running yet.
What's the problem with defining daylight saving time yourself? All functions for this are there
stringo:
Yedelkin:
the question is very relevant and interesting not only to you, but it is not the only one to which we will not get an answer - it's policy. he who pays the piper calls the tune
Well, what's the point of hiding information about the time of the championship server and the presence/absence of daylight saving time?
For example, the championship server hasn't launched yet.
Well, the failure to launch the server is hardly relevant to the thesis of "he who pays the piper calls the tune. :) The point of using this thesis I was trying to understand :)
What's the problem with defining the changeover to winter time yourself? All the functions are there
Yes, the problem seems to be a bit different. If trades must be executed only at 18.00 CET, it is very convenient if the server time completely coincides with CET time, or if daylight saving time in CET zone and server time are synchronized. Then you only have to write one line like "if(TimeCurrent()==18.00) - trade" in the trading block, and don't have to think about checking whether daylight saving time in CET zone and on the server is done.
I have to check anyway, because I've decided to trade according to local time in different countries. The Japanese, for example, don't switch to daylight saving time. If I want to trade from 12 am to 2 pm (Tokyo time), I have to check for DST on my trading server, since it is already implemented in my server. Canadians have a slightly different timing for daylight saving time, etc.
Yes, the problem seems to be a little different. If trades should be made only at 18.00 CET, it is very convenient if server time is completely the same as CET time, or if daylight saving time transitions in CET zone and server time are synchronized. Then you only have to write one line like "if(TimeCurrent()==18.00) - trade" in block of trade, and not to think about checking, whether daylight saving time in CET zone and on server time is done.
I have to check anyway, because I've decided to try and trade according to local time in different countries. The Japanese, for example, don't switch to daylight saving time. So, in order to trade at 12:00 am Tokyo time I have to check for DST switch back on the server (as it is a standard feature). Canadians have slightly different return times, etc.
No problem. You know what time it is relative to financial centres, you know if they are daylight saving time or not (at least you can find out), it is possible to calculate GMT time.
I see no problem calculating the time for any of the existing financial centres.
The strategy tester will be a bit tricky, but it is manageable.
No problem. The relative times of the financial centres are known, whether or not they switch to daylight saving time is also known (at least it is possible to find out), it is possible to calculate GMT time in principle.
I see no problem calculating the time for any of the existing financial centres.
I'm not saying that tracking back to winter time is a problem. But, compared to one line like "if(TimeCurrent()==18.00) - trade", additional lines of code for tracking - does not add any elegance or speed to the code :)
Yes, the problem seems to be a little different. If trades should be made only at 18.00 CET, it is very convenient if server time is completely the same as CET time, or if daylight saving time transitions in CET zone and server time are synchronized. Then you only have to write one line like "if(TimeCurrent()==18.00) - trade" in the trading block, and don't have to think about checking whether daylight saving time in CET zone and on the server is done.
I have to check anyway, because I've decided to trade according to local time in different countries. The Japanese, for example, don't switch to daylight saving time. If I want to trade from 12 am to 2 pm (Tokyo time), I have to check DST on my trading server, since it is already implemented in my server. Canadians have a slightly different timing for daylight saving time, etc.
1) What happens if you don't trade on the day of the switch?
2. Do you want to be in control? In that case study MQL5. All options for determining the fact of switching to winter time are presented. Initially.