Автоподмена параметра времени начала торговли TimeStart = (TimeLocal - TimeCurrent)

Новый комментарий
 

В параметрах советника время начала торговли TimeStart = 12
Если переход на зимнее - летнее время или другой часовой пояс, то этот параметр будет уже не актуален,
т.к. в тестере старт осуществится в 12 часов, а в реальной торговле по локальному времени в >=13 часов, или в <=11 часов (зависит от часового пояса) 
Т.е. чтобы в ручную не менять параметр (например время МСК) TimeStart = 11, иначе старт будет в 13 часов

 

Проще всего тогда привязываться ко времени Гринвича (TimeGMT()), т. к. у него нет перехода на зимнее/летнее время.

Озвученная же проблема не совсем понятна, т. к. неясно, что именно должен задавать параметр TimeStart. Если это локальное время, то его не нужно приводить - просто сравниваем с TimeLocal(). Если это время сервера, то тоже ничего не делаем - сравниваем с TimeCurrent(). Если нужно, чтобы это время относилось к какой-либо новости, то нужно взять часовой пояс той местности, для которой выходит новость. 

 
А почему не почитать документацию?

Там есть функция TimeDaylightSavings(); - Возвращает признак перехода на летнее /зимнее время.
И ещё есть TimeGMTOffset(); - Возвращает текущую разницу между временем GMT и локальным временем компьютера в секундах с учетом перехода на зимнее или летнее время.

Имея эти данные можно легко посчитать нужное время.
 
Alexey Viktorov:
А почему не почитать документацию?

Там есть функция TimeDaylightSavings(); - Возвращает признак перехода на летнее /зимнее время.
И ещё есть TimeGMTOffset(); - Возвращает текущую разницу между временем GMT и локальным временем компьютера в секундах с учетом перехода на зимнее или летнее время.

Имея эти данные можно легко посчитать нужное время.

А если используем тестер стратегий? TimeGMT() равен TimeCurrent(). Как быть?

 
Evgeniy Lapkin:

А если используем тестер стратегий? TimeGMT() равен TimeCurrent(). Как быть?

А ваш вопрос ещё более туманен.

 
Alexey Viktorov:

А ваш вопрос ещё более туманен.

Столкнулся с похожей проблемой, но она связана с тестером стратегий. 

в тестере TimeGMT = TimeCurrent. Как понять, был ли перевод времени на зимнее/летнее при условии, что брокер тоже время переводит? У такого брокера что до перевода было 12.00 время сервера, по GMT - 10.00, что после перевода осталось 12.00, но по GMT уже 11.00. Вот и возникли сложности, как же всё таки в тестере осуществить проверку времени.

 
Evgeniy Lapkin:

Столкнулся с похожей проблемой, но она связана с тестером стратегий. 

в тестере TimeGMT = TimeCurrent. Как понять, был ли перевод времени на зимнее/летнее при условии, что брокер тоже время переводит? У такого брокера что до перевода было 12.00 время сервера, по GMT - 10.00, что после перевода осталось 12.00, но по GMT уже 11.00. Вот и возникли сложности, как же всё таки в тестере осуществить проверку времени.

что делает конкретный брокер - никто не сможет сказать)

Но время перевода стрелок общеизвестно.
То есть нужно самому сделать функцию определения времени перевода, и самому переводить, или не переводить свои стрелки, в зависимости от конкретного брокера.

 

Недавно разбирался с определением перехода на зимнее время. Похоже, что внутри тестера только на mql задачу не решить.

Если знать в какой зоне расположен сервер брокера, то можно, используя вызовы dll, получить информацию о датах переходов или наличию смещения на указанную дату.

По итогам с заказчиком решили, что оно того не стоит и проще в параметрах прописать даты переходов за несколько прошлых лет и несколько лет вперед.

Была еще одна идея, определять по времени началу торгов в понедельник.
 
Ilya Baranov:

Недавно разбирался с определением перехода на зимнее время. Похоже, что внутри тестера только на mql задачу не решить.

Если знать в какой зоне расположен сервер брокера, то можно, используя вызовы dll, получить информацию о датах переходов или наличию смещения на указанную дату.

По итогам с заказчиком решили, что оно того не стоит и проще в параметрах прописать даты переходов за несколько прошлых лет и несколько лет вперед.

а в чем проблема? найти последнее воскресенье месяца?
это можно посчитать в мкл

 
Taras Slobodyanik:

а в чем проблема? найти последнее воскресенье месяца?
это можно посчитать в мкл

Например в США и в Великобритании переход в разное время, а в некоторых зонах переход отсутствует.

Например:

UTC+2:00 Калининград - нет перехода

UTC+2:00 Иерусалим - есть переход

Так что простым методом можно решить задачу только для частной зоны. Более сложно - обращаться к ОС через dll или портировать более серьезный код.
 
Ilya Baranov:

Например в США и в Великобритании переход в разное время, а в некоторых зонах переход отсутствует.

Например:

UTC+2:00 Калининград - нет перехода

UTC+2:00 Иерусалим - есть переход

так флаг перехода вынести в параметры и всё - хочет юзер тестировать с переходом - включает опцию, не хочет - не включает

12
Новый комментарий