Добротная статья. Правда, возникает одна проблема: как определить, что брокер\дилер переходит с зимнего\летнего, не обращаясь в его техподдержку?
- www.mql5.com
- Почему бы не спросить?
- Программа знает, когда в США и ЕС летнее/зимнее время, и использует это для расчета смещения брокера.
1. Потому что поддержка не всегда выдает корректную информацию. Вы сами это указали про дилера Альпари. + это накладно: выяснить у каждого дилера переход. Ведь тогда не получается создать хорошего решения, я не знаю, конечный пользователь у кого обсулживается.
2. Ну, вроде как, да, но вот если дилер не переход с зимнего на летнее и обратно, то получается в расчетах какая-то странная штука.
Я попробовал чутка модифицировать вашу библиотеку, но, видимо, что-то не так пошло. Думал код привести к тому, что советник автоматически определяет время GMT и торгует именно по GMT, а не по серверу брокера. Не уверен, что код оптимальный, но решение, кажется, работает. Правда, у тех дилеров, что время не меняют - там получаются какие-то неверные расчеты.
1. Потому что поддержка не всегда выдает корректную информацию. Вы сами это указали про дилера Альпари. + это накладно: выяснить у каждого дилера переход. Ведь тогда не получается создать хорошего решения, я не знаю, конечный пользователь у кого обсулживается.
2. Ну, вроде как, да, но вот если дилер не переход с зимнего на летнее и обратно, то получается в расчетах какая-то странная штука.
Я попробовал чутка модифицировать вашу библиотеку, но, видимо, что-то не так пошло. Думал код привести к тому, что советник автоматически определяет время GMT и торгует именно по GMT, а не по серверу брокера. Не уверен, что код оптимальный, но решение, кажется, работает. Правда, у тех дилеров, что время не меняют - там получаются какие-то неверные расчеты.
- Что вы изменили?
- Можете ли вы назвать мне брокера (ссылка), где это не работает?
- Я только что использовал его снова:
for (i=start; i<rates_total && ! IsStopped (); i++) { checkTimeOffset( time[i]); tGMT = time[i] + OffsetBroker.actOffset; // GMT }
- Что вы изменили?
- Можете ли вы назвать мне брокера (ссылка), где это не работает?
- Я только что использовал его снова:
1.
- не стал зацикливаться на EURUSD, туда, куда поставлен советник, ту пару и берем.
- время тоже не стал жестко фиксировать, я просто отнимаю 1 год от текущего.
datetime setDate = StringToTime(IntegerToString(NowYear()-1)+".06.21 14:00"); nextDST("EUR", setDate); // EUR: get DST and set next change
И по ссылке передаю параметры bool setBokerOffset(string symbol, int &USwinEUwin1, int &USsumEUsum1, int &USsumEUwin1), что их динамично получить вот это блок
input int USwinEUwin= -7200; // US=Winter & EU=Winter input int USsumEUsum= -10800; // US=Summer & EU=Summer input int USsumEUwin= -7200; // US=Summer & EU=Winter
2. Альфа-форекс. Могу в лс дать данные от демо-счета, чтобы вы могли проверить, не открывая ничего. Дело в том, что дилер не переходит с зимнего на летнее, а разница с GMT все равно возникает.
3. Немного не понял, как и где использована конструкция.
Вообще перешел на гринвич. И время перехода на зимнее определяю как разницу серверного времени и гринвича. Единственно, что для каждого брокера эту разницу приходится считать самому и забивать в константы советника. Просто когда у пользователей разные сдвиги, у брокеров, у бирж, и время перехода на зимнее не одинаково, гринвич одинаков для всех.
А как именно вы это сделали? Каким образом высчитывается константы?
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Работаем со временем (Часть 2): Функции:
Научимся автоматически распознавать смещения времени у брокера и время по Гринвичу. Вместо того, чтобы обращаться к брокеру, который скорее всего даст недостаточно полный ответ (а кто захочет объяснять, куда пропал торговый час?), мы сами посмотрим, по какому времени приходят от них котировки в те недели, когда переводят часы. Но конечно же, это мы будем делать не вручную — пусть за нас работает программа.
В этой статье мы продолжим работать с include-файлом DealingWithTime.mqh, с которым работали в первой части. В этом файле до функций и после макро-подстановок идут необходимые переменные, которые объявлены как глобальные переменные:
Эти переменные DST_USD, DST_EUR, и т.д. будут принимать фактическое значение смещения времени в соответствующих странах и регионах — США, Европа и т.д. Значения переменных будут заполняться функциями. В нормальное зимнее время значения равны нулю: время в этот период не смещается.
Далее у нас идут переменные с датой предстоящего перевода часов. Они указывают, когда нужно будет рассчитывать новые значения переменных, чтобы не проводить ненужные расчеты до этого и не тратить вычислительные ресурсы:
Тут есть небольшое отличие в настройках для России, мы рассмотрим ее чуть позже.
Данная структура и ее глобальная переменная являются сердцем всей программы. :)
Автор: Carl Schreiber