Таймзона пользователя (терминала) и источника события
Но ведь в запросе CalendarValueHistory, время GMT, а не время терминала, да и в структуру пишется время GMT. Да и тот факт, что одна новость видна, а другая нет при всех одинаковых параметрах.
Я конечно не собираюсь спорить с программистами грамотнее меня, но что-то тут логики не видно. Ведь если время новости указано 1:30 и запрос делается от 1:00 до 2:00 то эта новость должна быть видна не зависимо от времени МТ. А когда делается запрос от 1:00 до 4:00 вдруг эта новость находится и время новости определяется как 1:30. При всём при том другие даты указанные в моём примере работают без проблем с диапазоном времени 1 час.
И поскольку сейчас идёт работа по экономическому календарю, хочу попросить, чтобы была возможность задать диапазон времени, ну хотя-бы 5 минут, если уж не получится запрашивать новости в диапазоне времени 1:30 до 1:31 Правда я должен признаться, я не проверял какой минимальный диапазон допустим.
Alexey Viktorov: Но ведь в запросе CalendarValueHistory, время GMT, а не время терминала, да и в структуру пишется время GMT.
Добавляем примечание к функциям календаря
Примечание
Все функции для работы с Экономическим календарем используют время торгового сервера (TimeTradeServer). Это означает, что время в структуре MqlCalendarValue и входящие параметры времени в функциях CalendarValueHistoryByEvent/CalendarValueHistory задаются в таймзоне торгового сервера, а не в локальном времени пользователя.
Все функции для работы с Экономическим календарем используют время торгового сервера (TimeTradeServer). Это означает, что время в структуре MqlCalendarValue и входящие параметры времени в функциях CalendarValueHistoryByEvent/CalendarValueHistory задаются в таймзоне торгового сервера, а не в локальном времени пользователя.
Спасибо, на одном проблемном участке проверил. Всё как доктор прописал.
2019.08.3016:54:21.134 Test bag (AUDUSD,H1) Получены значения событий по country_code=AU: 42019.08.3016:54:21.134 Test bag (AUDUSD,H1) date_from 2019.08.1504:30:00 : date_to 2019.08.1504:31:002019.08.3016:54:21.134 Test bag (AUDUSD,H1) [id] [event_id] [time] [period] [revision] [actual_value] [prev_value] [revised_prev_value] [forecast_value] [impact_type] [reserved]
2019.08.3016:54:21.134 Test bag (AUDUSD,H1) [0] 93908360100042019.08.1504:30:002019.07.0100:00:000345000002110000021000000 -9223372036854775808002019.08.3016:54:21.134 Test bag (AUDUSD,H1) [1] 93909360100052019.08.1504:30:002019.07.0100:00:0006610000066000000 -922337203685477580866100000002019.08.3016:54:21.134 Test bag (AUDUSD,H1) [2] 93910360100032019.08.1504:30:002019.07.0100:00:00041100000500000 -230000026800000102019.08.3016:54:21.134 Test bag (AUDUSD,H1) [3] 93911360100062019.08.1504:30:002019.07.0100:00:00052000005200000 -9223372036854775808510000020
Если знаете точное время новости можно задать диапазон запроса 1 минуту. Но надо учитывать что date_to не входит в диапазон. То-есть, если задать время
Наш сервис собирает самостоятельно исходные данные со множества официальных источников и настроен на максимально быструю реакцию. Кроме того, ведется глубокая история значений.
Сначала мы включим календарь на этом сайте, а потом проапгрейдим календарь в МТ5 и дадим прямой доступ ко всем данным календаря из MQL5. Можно будет использовать календарь и в тестере - его история тоже будет моделироваться.
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
Спасибо, причину выяснили - разные таймзоны. Сообщим как будет найдено решение.
Имеете ввиду таймзоны стран?
Имеете ввиду таймзоны стран?
Таймзона пользователя (терминала) и источника события
Таймзона пользователя (терминала) и источника события
Я конечно не собираюсь спорить с программистами грамотнее меня, но что-то тут логики не видно. Ведь если время новости указано 1:30 и запрос делается от 1:00 до 2:00 то эта новость должна быть видна не зависимо от времени МТ. А когда делается запрос от 1:00 до 4:00 вдруг эта новость находится и время новости определяется как 1:30. При всём при том другие даты указанные в моём примере работают без проблем с диапазоном времени 1 час.
И поскольку сейчас идёт работа по экономическому календарю, хочу попросить, чтобы была возможность задать диапазон времени, ну хотя-бы 5 минут, если уж не получится запрашивать новости в диапазоне времени 1:30 до 1:31 Правда я должен признаться, я не проверял какой минимальный диапазон допустим.
Время выхода новости может изменятся на час
И что? В какое время может произойти изменение? Непосредственно в назначенное время вместо новости происходит изменение времени?
Но ведь в запросе CalendarValueHistory, время GMT, а не время терминала, да и в структуру пишется время GMT.
Добавляем примечание к функциям календаря
Примечание
Все функции для работы с Экономическим календарем используют время торгового сервера (TimeTradeServer). Это означает, что время в структуре MqlCalendarValue и входящие параметры времени в функциях CalendarValueHistoryByEvent/CalendarValueHistory задаются в таймзоне торгового сервера, а не в локальном времени пользователя.
Добавляем примечание к функциям календаря
Примечание
Все функции для работы с Экономическим календарем используют время торгового сервера (TimeTradeServer). Это означает, что время в структуре MqlCalendarValue и входящие параметры времени в функциях CalendarValueHistoryByEvent/CalendarValueHistory задаются в таймзоне торгового сервера, а не в локальном времени пользователя.
Спасибо, на одном проблемном участке проверил. Всё как доктор прописал.
Если знаете точное время новости можно задать диапазон запроса 1 минуту. Но надо учитывать что date_to не входит в диапазон. То-есть, если задать время
События экономического календаря из примера выше, не будут получены.
Renat Fatkhullin:
Мы уже сделали собственную лицензионно чистую реализацию экономического календаря.
Наш сервис собирает самостоятельно исходные данные со множества официальных источников и настроен на максимально быструю реакцию. Кроме того, ведется глубокая история значений.
Сначала мы включим календарь на этом сайте, а потом проапгрейдим календарь в МТ5 и дадим прямой доступ ко всем данным календаря из MQL5. Можно будет использовать календарь и в тестере - его история тоже будет моделироваться.
__________________
видать в тестере это еще не реализовано