Ещё раз о UTC (GMT) - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если требуется привязка работы советников к универсальному времени UTC, сейчас вижу 2 пути:
1. Полностью автоматизированный. Полагаться на правильные настройки компьютера на котором запущен терминал и TimeGMT()
2. Полу-автоматизированный. Вручную задавать смещение времени сервера относительно UTC (а также даты смены лето-зима)
При этом для тестирования подходит только путь 2. У обоих путей есть минусы.
Кто-нибудь знает способ полностью автоматизированный и чтобы не зависеть от настроек локального компьютера? или другими словами
Можно ли получить время GMT по настройкам сервера, на котором установлена серверная часть МТ, а не локального компьютера?
Не знаю пути, чтобы не зависеть от текущего системного времени на компьютере. Больше десяти лет использую путь, основанный на синхронизации этого времени с астрономическим по нескольким десяткам публичных (бесплатных) серверов NTP. Не знаю, подойдет ли для его реализации Webrequest, который к тому же синхронен, то есть параллельно отослать десять запросов а затем проверять, пришли ли ответы в буфер сетевой карты, в нем нельзя. Полагаться на бесплатные источники можно, но не на один. Они иногда не отвечают (NTP реализован на UDP, а не TCP, соединение как таковое не устанавливается вообще). Первая версия такой синхронизации имела список лишь 50 серверов, и проработала 6 месяцев - стали отвечать лишь 6 из нужных мне 13. Вторая содержит 79 серверов в списке вида
'a.ntp.alphazed.net', '88.96.233.89'
'a.ntp.madduck.net', '213.203.238.86'
'asynchronos.iiss.at', '83.64.124.251'
...
'www.millnet.se', '85.8.21.133'
'zeit.fu-berlin.de', '160.45.10.8'
Если кто пойдет по этому пути, весь список серверов, отобранных из 600 претендентов по постоянству наличия и времени реакции, прилагаю. Поведение серверов с тех пор (2010 год), конечно, уже изменилось. Но некоторые имеют и соблюдают традиции. Не ужасайтесь числу серверов в списке, реально из них берутся для каждой синхронизации лишь 13, ответы ранжируются по качеству и усредняются, системное время компьютера подправляется только в случае отклонения от астрономического на 12 мс или больше.
Имея уверенное системное время на локальном компьютере, дальше просто - разность TimeCurrent и TimeLocal.
Не ужасайтесь числу серверов в списке, реально из них берутся для каждой синхронизации лишь 13, ответы ранжируются по качеству и усредняются, системное время компьютера подправляется только в случае отклонения от астрономического на 12 мс или больше.
Зачем 13 запросов, зачем точное время? На компе и так точное время, разница только в часах. Достаточно одного удачного запроса и вычислите разницу в часах.
Если у Вас есть опыт работы с NTP, дайте код или ссылку на него для реализации в MQL5, кто-то захочет сделать.
PS. Сервера NTP, прописанные в Windows и Linux не перестают работать со временем.
Зачем 13 запросов, зачем точное время? На компе и так точное время, разница только в часах. Достаточно одного удачного запроса и вычислите разницу в часах.
Если у Вас есть опыт работы с NTP, дайте код или ссылку на него для реализации в MQL5, кто-то захочет сделать.
PS. Сервера NTP, прописанные в Windows и Linux не перестают работать со временем.
Если
- не предъявлять претензии к ДЦ, где основанием для разбора являются лог-файлы сервера с временем в миллисекундах;
- не работать с партнерами по сети с ведением протоколов прихода тиков от каждого ДЦ по миллисекундам;
то я тоже не знаю, зачем. Для выяснения часового пояса ДЦ хватит и обычной точности таймера, накапливающего по моему опыту не больше 2 минут погрешности за неделю вообще без синхронизации.
MQL, хоть 4, хоть 5, здесь ни при чем. Ссылка на источник - компоненты VCL библиотеки Borland Delphi 7, Indy. Ну, конечно, еще и протокол UDP. Я лишь переделал нужные функции в асинхронную работу и конкретизировал, у кого спрашивать время, как часто, и что делать с результатами.
Насчет Linux не интересовался, а прописанные в Windows сервера не NTP, а NTPS (simple, упрощенный протокол, с собственной погрешностью около 1000 мс).
Если
- не предъявлять претензии к ДЦ, где основанием для разбора являются лог-файлы сервера с временем в миллисекундах;
- не работать с партнерами по сети с ведением протоколов прихода тиков от каждого ДЦ по миллисекундам;
то я тоже не знаю, зачем. Для выяснения часового пояса ДЦ хватит и обычной точности таймера, накапливающего по моему опыту не больше 2 минут погрешности за неделю вообще без синхронизации.
MQL, хоть 4, хоть 5, здесь ни при чем. Ссылка на источник - компоненты VCL библиотеки Borland Delphi 7, Indy. Ну, конечно, еще и протокол UDP. Я лишь переделал нужные функции в асинхронную работу и конкретизировал, у кого спрашивать время, как часто, и что делать с результатами.
Насчет Linux не интересовался, а прописанные в Windows сервера не NTP, а NTPS (simple, упрощенный протокол, с собственной погрешностью около 1000 мс).
нету такого протокола NTPs
вы что-то не там слышали и сбивчиво пересказываете
есть незначительные расширения NTP касаемые шифрований и защиты, но они ничуть не снижают прочих характеристик NTP
Если
- не предъявлять претензии к ДЦ, где основанием для разбора являются лог-файлы сервера с временем в миллисекундах;
- не работать с партнерами по сети с ведением протоколов прихода тиков от каждого ДЦ по миллисекундам;
то я тоже не знаю, зачем. Для выяснения часового пояса ДЦ хватит и обычной точности таймера, накапливающего по моему опыту не больше 2 минут погрешности за неделю вообще без синхронизации.
MQL, хоть 4, хоть 5, здесь ни при чем. Ссылка на источник - компоненты VCL библиотеки Borland Delphi 7, Indy. Ну, конечно, еще и протокол UDP. Я лишь переделал нужные функции в асинхронную работу и конкретизировал, у кого спрашивать время, как часто, и что делать с результатами.
Насчет Linux не интересовался, а прописанные в Windows сервера не NTP, а NTPS (simple, упрощенный протокол, с собственной погрешностью около 1000 мс).
Я наивно думал что в цифровой век 2 минуты в неделю должно считаться огромной неточностью. Дедовские часы механические и те точнее. Как такая погрешность-откуда возникает?
Я вот тему эту не увидел, я спрашивал про историю и GMT сдвиг https://www.mql5.com/ru/forum/331194
Заметил непонятную для меня вещь ещё:
1) У брокеров с одинаковым GMT на истории сдвиг есть
2) А у брокеров с разным GMT на истории нет сдвига
Это в ступор заводит...
А текущее время на 0 свечке показывает правильно. Вот что это?
Я вот тему эту не увидел, я спрашивал про историю и GMT сдвиг https://www.mql5.com/ru/forum/331194
Заметил непонятную для меня вещь ещё:
1) У брокеров с одинаковым GMT на истории сдвиг есть
2) А у брокеров с разным GMT на истории нет сдвига
Это в ступор заводит...
это с одинаковым GMT
это с разным GMT
А текущее время на 0 свечке показывает правильно. Вот что это?
Интересно что за непонятка, чувствую что ответ на поверхности и просто затуп, но не понимаю в чём именно.
з.ы. прикольно у вас секунды на скринах сложились в ряд - 33,44,33,44