Обсуждение статьи "Работаем со временем (Часть 2): Функции"

 

Опубликована статья Работаем со временем (Часть 2): Функции:

Научимся автоматически распознавать смещения времени у брокера и время по Гринвичу. Вместо того, чтобы обращаться к брокеру, который скорее всего даст недостаточно полный ответ (а кто захочет объяснять, куда пропал торговый час?), мы сами посмотрим, по какому времени приходят от них котировки в те недели, когда переводят часы. Но конечно же, это мы будем делать не вручную — пусть за нас работает программа.

В этой статье мы продолжим работать с include-файлом DealingWithTime.mqh, с которым работали в первой части. В этом файле до функций и после макро-подстановок идут необходимые переменные, которые объявлены как глобальные переменные:

//--- глобальные переменные для смены времени
int      DST_USD=0,                             // фактическое смещение времени для США
         DST_EUR=0,                             // фактическое смещение времени для Европы
         DST_AUD=0,                             // фактическое смещение времени для Австралии
         DST_RUS=0;                             // D'2014.10.26 02:00', -10800,


Эти переменные DST_USD, DST_EUR, и т.д. будут принимать фактическое значение смещения времени в соответствующих странах и регионах — США, Европа и т.д. Значения переменных будут заполняться функциями. В нормальное зимнее время значения равны нулю: время в этот период не смещается.

Далее у нас идут переменные с датой предстоящего перевода часов. Они указывают, когда нужно будет рассчитывать новые значения переменных, чтобы не проводить ненужные расчеты до этого и не тратить вычислительные ресурсы:

datetime nxtSwitch_USD,                         // дата следующего перехода
         nxtSwitch_EUR,                         // дата следующего перехода
         nxtSwitch_AUD,                         // дата следующего перехода
         nxtSwitch_RUB = D'2014.10.26 02:00';   // для России по-другому :(


Тут есть небольшое отличие в настройках для России, мы рассмотрим ее чуть позже.

Данная структура и ее глобальная переменная являются сердцем всей программы. :)

struct _OffsetBroker
  {
   int   USwinEUwin,                            // US=Winter & EU=Winter
         USsumEUsum,                            // US=Summer & EU=Summer
         USsumEUwin,                            // US=Summer & EU=Winter
         actOffset,                             // фактическое смещение времени брокера
         secFxWiWi,                             // продолжительность работы рынка в сек
         secFxSuSu,                             // продолжительность работы рынка в сек
         secFxSuWi,                             // продолжительность работы рынка в сек
         actSecFX;                              // фактическая продолжительность работы рынка в сек
   bool  set;                                   // вес установили?
  };
_OffsetBroker OffsetBroker;


Автор: Carl Schreiber

 
Добротная статья. Правда, возникает одна проблема: как определить, что брокер\дилер переходит с зимнего\летнего, не обращаясь в его техподдержку?
 
Nikita Chernyshov # :
Добротная статья. Правда, возникает одна проблема: как определить, что брокер\дилер переходит с зимнего\летнего, не обращаясь в его техподдержку?
  1. Почему бы не спросить?
  2. Программа знает, когда в США и ЕС летнее/зимнее время, и использует это для расчета смещения брокера.
 
Nikita Chernyshov #:
Добротная статья. Правда, возникает одна проблема: как определить, что брокер\дилер переходит с зимнего\летнего, не обращаясь в его техподдержку?


.
Документация по MQL5: Дата и время / TimeDaylightSavings
Документация по MQL5: Дата и время / TimeDaylightSavings
  • www.mql5.com
TimeDaylightSavings - Дата и время - Справочник MQL5 - Справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5
 
Alexey Viktorov #:


.

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

 
Carl Schreiber #:
  1. Почему бы не спросить?
  2. Программа знает, когда в США и ЕС летнее/зимнее время, и использует это для расчета смещения брокера.

1. Потому что поддержка не всегда выдает корректную информацию. Вы сами это указали про дилера Альпари. + это накладно: выяснить у каждого дилера переход. Ведь тогда не получается создать хорошего решения, я не знаю, конечный пользователь у кого обсулживается.

2. Ну, вроде как, да, но вот если дилер не переход с зимнего на летнее и обратно, то получается в расчетах какая-то странная штука.

Я попробовал чутка модифицировать вашу библиотеку, но, видимо, что-то не так пошло. Думал код привести к тому, что советник  автоматически определяет время GMT и торгует именно по GMT, а не по серверу брокера. Не уверен, что код оптимальный, но решение, кажется, работает. Правда, у тех дилеров, что время не меняют - там получаются какие-то неверные расчеты.

Файлы:
 
Nikita Chernyshov # :

1. Потому что поддержка не всегда выдает корректную информацию. Вы сами это указали про дилера Альпари. + это накладно: выяснить у каждого дилера переход. Ведь тогда не получается создать хорошего решения, я не знаю, конечный пользователь у кого обсулживается.

2. Ну, вроде как, да, но вот если дилер не переход с зимнего на летнее и обратно, то получается в расчетах какая-то странная штука.

Я попробовал чутка модифицировать вашу библиотеку, но, видимо, что-то не так пошло. Думал код привести к тому, что советник  автоматически определяет время GMT и торгует именно по GMT, а не по серверу брокера. Не уверен, что код оптимальный, но решение, кажется, работает. Правда, у тех дилеров, что время не меняют - там получаются какие-то неверные расчеты.

  1. Что вы изменили?
  2. Можете ли вы назвать мне брокера (ссылка), где это не работает?
  3. Я только что использовал его снова:
     for (i=start; i<rates_total && ! IsStopped (); i++) {
          checkTimeOffset( time[i]);
          tGMT           = time[i] + OffsetBroker.actOffset; // GMT 
    
    }


     
    Carl Schreiber #:
    1. Что вы изменили?
    2. Можете ли вы назвать мне брокера (ссылка), где это не работает?
    3. Я только что использовал его снова:


      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. Немного не понял, как и где использована конструкция. 

       

      3. Немного не понял, как и где использована конструкция.

      In an indicator that is the top of the loop though all bars.

       
      Вообще перешел на гринвич. И время перехода на зимнее определяю как разницу серверного времени и гринвича. Единственно, что для каждого брокера эту разницу приходится считать самому и забивать в константы советника. Просто когда у пользователей разные сдвиги, у брокеров, у бирж, и время перехода на зимнее не одинаково, гринвич одинаков для всех.
       
      Valeriy Yastremskiy #:
      Вообще перешел на гринвич. И время перехода на зимнее определяю как разницу серверного времени и гринвича. Единственно, что для каждого брокера эту разницу приходится считать самому и забивать в константы советника. Просто когда у пользователей разные сдвиги, у брокеров, у бирж, и время перехода на зимнее не одинаково, гринвич одинаков для всех.

      А как именно вы это сделали? Каким образом высчитывается константы?

      Причина обращения: