OBJPROP_CREATETIME выдаёт не правильное время - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А никого не смущает, что серверное время не поступает в выходные? Скрипт, предъявленный выше, возвращает время UTC без коррекции на летнее.
Угу. Получается время по стоящему серверному времени с переводом на GMT.
А никого не смущает, что серверное время не поступает в выходные? Скрипт, предъявленный выше, возвращает время UTC без коррекции на летнее.
2) Дата создания объекта возвращается по GMT. Вы не находите это странным? Мы создаём объект на графике, а время GMT. При чём тут оно? Вполне логично чтобы это было серверное время.
Не находим это странным.
Это время создания объекта ВАМИ. Вне зависимости от выходных или праздничных дней и времени торгового сервера. А какое время назначать создаваемому объекту при отсутствии связи с торговым сервером?
Не находим это странным.
Это время создания объекта ВАМИ. Вне зависимости от выходных или праздничных дней и времени торгового сервера. А какое время назначать создаваемому объекту при отсутствии связи с торговым сервером?
Не находим это странным.
Это время создания объекта ВАМИ. Вне зависимости от выходных или праздничных дней и времени торгового сервера. А какое время назначать создаваемому объекту при отсутствии связи с торговым сервером?
Есть еще локальное время компьютера. Оно всегда доступно. Тем более, такой принцип используется при ведении логов. Почему бы не унифицировать? А то получаем три разных времени в одном терминале: здесь - серверное время, там локальное, а теперь еще про GMT нужно помнить...
Думаю когда будет переводится время, может произойти колизия когда объект может иметь время создания в будущем.
chr-файлы можно переносить с одного компьютера на другой, от одного терминала к другому. Поэтому GMT - наилучший вариант. А с недавнего времени появился хостинг терминалов.
chr-файлы переносятся на хостинг при миграции (а на хостинге заранее неизвестное локальное время).
chr-файлы можно переносить с одного компьютера на другой, от одного терминала к другому. Поэтому GMT - наилучший вариант. А с недавнего времени появился хостинг терминалов.
chr-файлы переносятся на хостинг при миграции (а на хостинге заранее неизвестное локальное время).
Отлично! Значит следующий по логике шаг - перевод журналов на время GMT. За ним должен последовать еще более правильный шаг - перевод серверного времени на GMT, чтобы решить, наконец, проблему идентичности графиков. Такой подход является последовательным.
На данный же момент имеем: время привязки объекта (если это не LABEL и пр. подобные объекты) - серверное, время создания объекта - GMT, время в журналах - локальное. С точки зрения разработчика, вроде бы, логично, но с точки зрения пользователя - солянка. Помнить подобные нюансы при разработке программ на MQL4/5 достаточно затруднительно.