The clocks are changed to winter time on the night of the last Sunday in October, and daylight saving time is switched on the night of the last Sunday in March.
There is no more reliable way to calculate summer or winter time.
Time is translated differently in different countries.
Why talk about reliability without testing the algorithm in different conditions?
- www.worldtimezone.com
Author: Yuriy Zaytsev
You made a crooked bicycle, Yuri.
Time translates differently in different countries.
Why talk about reliability without testing the algorithm under different conditions?
Of course the world is diverse, but the way time is translated in Papua New Guinea or Nambia is not important.
what matters is how MQ brokers translate time. That's what the algorithm is designed to do.
and brokers change the time on the last Sunday in October and March.
and the algorithm reliably catches the last Sunday in March and October.
you've made a crooked bicycle, Yuri.
And what is a working bicycle analogue - is there another ready-made function ?
and what is the crookedness, doesn't the function work?
And if it works, then why is this phrase inappropriate?
what is important is how MQ brokers translate time
So we should start with the question - why is this code posted at all?
The broker's binding country is unknown, whether the broker translates time on the server is unknown. Whether his MT translates time is also unknown.
So what does this code define? Time zone and the principle of time translation in Europe? What does it have to do with the unknown state of the broker?
A code for the sake of realising "encyclopedic" knowledge?
Code for controlling news at times when America has not yet translated the time, Australia has already translated it and Europe is still asleep?
In general, what for why is not clear. code for code's sake.
Of course the world is diverse, but how time is translated in Papua New Guinea or Nambia is not important.
What matters is how the MQ brokers translate the time. That's what the algorithm is designed for.
and brokers change the time on the last Sunday in October and March.
and the algorithm reliably catches the last Sunday in March and October.
We do not touch Papua and Guinea, it is enough that America is different from Europe.
And what will change if you are in America or Europe and connect to the same dyling...?
The function is written for testing news events
And what changes if you are in America or Europe and still connect to the same dyling....
The function is written for testing news events
If the server is in America, it will have daylight saving time not at the same time as the server in Europe.
I.e. this function will work correctly with one dealing, and incorrectly with another.
If the server is in America, it will not have daylight saving time at the same time as the server in Europe.
I.e. this function will work correctly with one dealing, and incorrectly with another.
If you can, an example of two three dealing which have different time change from winter to summer time.
...
In the end:
The source is open algorithm is simple - if any dealing translates time to other dates - you can always correct.
The point is that this method relies on a fairly reliable way of determining the date,
I have a history of news events over a couple of years - tests have shown that after switching from summer to winter or from winter to summer.
the news release points coincide...
If you can give me an example of two or three dealings that have different time conversion from winter to summer.
Yuri, you're missing the point again.
If this code is for tracking news, it can't be tied to dealing.
News is a national thing, not a brokerage thing.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
YZ_Summer_Time:
Author: Yuriy Zaytsev