Лондонский отрыв - страница 2

 

Да, все это из-за IMO загадочного дизайнерского решения:) Так что время на сервере может даже не совпадать с известными мировыми часами в течение года.

У меня есть один метод точного определения времени по Гринвичу, особенно во время бэктестинга. Этот метод, похоже, работает для брокеров, которые

  • изменили TZ в середине своих исторических данных (Alpari),
  • или используют нестандартный DST против своего часового пояса (FXCM), как указывает Thirteen,

но подход все еще кажется мне немного халтурным.

Он включает загрузку котировок по GMT из других источников (dukascopy) и сравнение часа каждого дневного максимума. Для бэктестинга работает нормально, но в настоящее время я вручную загружаю часовые данные и фильтрую максимумы (с помощью perl-скрипта).

Как только я смогу автоматически получать котировки GMT H1 хотя бы из двух источников, тогда я буду уверен, что этот подход подходит для моих целей.

 
SDC:

Как можно сделать MT4 более подходящим для этого? Не знаю, как вы, но я бы точно не радовался задаче создания регионального исторического калькулятора смещения GMT. Вы только представьте? Если я когда-нибудь сделаю это, я выставлю его на рынок, и вам всем лучше иметь большую толстую чековую книжку ;)

Исторический калькулятор GMT сам по себе не особенно сложен (операционная система Windows уже содержит все необходимые данные), но это не главная проблема. Проблема в том, что вы можете определить текущее смещение между временем брокера и GMT, но вы не знаете, изменилось ли оно/когда. На примере выше вы можете увидеть, что брокер в настоящее время находится на GMT+3 (предполагая, что часы на локальном компьютере точны...), но вы не знаете, что на прошлой неделе брокер находился на GMT+2.

Вполне возможно, что клиентский терминал МТ4 просто не имеет этой информации.

Если бы она у него была, то MT4 мог бы предоставить либо голые данные, которые вы могли бы обработать самостоятельно, либо функцию, которая позволила бы вам сказать "конвертировать любую дату брокера в прошлом в GMT". Получив эти данные, вы могли бы использовать таблицу поиска (или Windows API) для преобразования исторического времени GMT в другой часовой пояс, например, Лондон. Однако было бы предпочтительнее, чтобы MT4 делал это за вас, например, с помощью пары функций, таких как следующая:

datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);

datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);

 
ydrol:

Да, и все это из-за непонятного дизайнерского решения IMO :)

(Я предполагаю, что причина не привязки к UTC заключается в том, чтобы брокеры могли работать в EET, давая пять свечей D1 в неделю, избегая шестой маленькой свечи, которая приводит к систематическим недооценкам таких вещей, как D1 ATR у брокеров, использующих GMTZ).
 
gchrmt4:
(Я предполагаю, что причина не привязки к UTC заключается в том, чтобы брокеры могли работать в EET, давая пять свечей D1 в неделю, избегая шестой маленькой свечи, которая приводит к систематическим недооценкам таких вещей, как D1 ATR у брокеров, использующих GMTZ).


Я бы поместил все эти вещи в клиент, но это усложняет клиент в разных местах :) Но, по крайней мере, все переменные известны.
 

Другой подход, согласно этой странице , существует только 62 брокера MT4? Поэтому не будет слишком сложно иметь таблицу поиска для каждого брокера и их определение времени (основано ли оно на реальном часовом поясе или комбинации, как у FXCM), а также учитывать исторические изменения (как у Alpari).

Это, вероятно, самый надежный подход, и его нужно будет подстраивать каждый раз, когда брокер решит, что хочет еще больше запутать своих клиентов :)

 

gchrmt4:

[1] Время вашего сервера GMT+3 может соответствовать EEST в том смысле, что EEST - это GMT+3, но, согласно Википедии и worldclock.com, нигде пока не должно быть EEST. Это изменение должно произойти не раньше 30 марта. Текущее время на Кипре, в Греции, Израиле и т.д. - GMT+2.

[2] Поэтому, скорее всего, у вас брокер работает на своих серверах по GMT+2, но переходит на летнее время в США, а не в Европе.

[3] Это не то же самое, что EET/EEST. (И это еще менее предсказуемо с точки зрения возможности написания кода, который автоматически корректирует время и даты без необходимости запрашивать у пользователя какие-то данные о том, какие настройки времени использует брокер).

  1. Правильно.
  2. Правильно.
  3. EET - это GMT+2, но GMT+2 - это не только EET. Также EEST - это GMT+3, но GMT+3 - это не только EEST. Описывая часовой пояс моего брокера как EET/EEST, я лишь хотел сказать, что это GMT+2 при стандартном времени и GMT+3 при переходе на летнее время, тем более что в этой теме обсуждается лондонский прорыв. Прошу прощения, если мое описание привело к некоторой путанице. :)

Если, таким образом, брокер недавно перешел с GMT+2 на GMT+3, а не собирается перейти с GMT+3 на GMT+4, это означает, что текущее смещение между временем брокера и GMT было бы неверным, если бы вы попытались применить его к барам на прошлой неделе, до перевода часов в США. На этой неделе бары брокера опережают Лондон на 3 часа. На прошлой неделе они были на 2 часа впереди. (А с 30 марта они снова будут опережать на 2 часа). Если вы возьмете текущее смещение в 3 часа и попытаетесь с его помощью получить цену в 8 утра по лондонскому времени в день на прошлой неделе, вы получите неверный ответ.

Брокер обычно не меняет часовой пояс своего сервера часто, за исключением перехода на летнее время. Для корректировки перехода на летнее время я могу использовать любую дату/время (от 1987 (США) и 1996 (ЕС) до 2020 и далее) и вычислить для США и ЕС день начала перехода на летнее время и день окончания перехода на летнее время. Получив этот код, вам останется только скорректировать текущее смещение относительно GMT, чтобы учесть переход на летнее время для рассматриваемого вами времени.

С помощью функции TimeGMT(), которая появилась в билде 600+, вы вычисляете текущее смещение вашего брокера относительно GMT. Но нельзя (насколько я знаю) определить часовой пояс брокера из прошлого. Например, у меня брокер изменил часовой пояс своего сервера с GMT для стандартного времени на GMT+2 для стандартного времени. Я справился с этой проблемой, жестко закодировав смещение для времени до перехода, поскольку все данные истории были GMT, а не GMT+2 (и я не хотел изменять историю, чтобы отразить GMT+2). В этом отношении, я думаю, мы с вами согласны. Пока брокер не меняет часовые пояса (кроме как для перехода на летнее время), вы должны иметь возможность рассчитать смещение относительно GMT и скорректировать это смещение для перехода на летнее время.

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

Кажется, я с вами не согласен. До тех пор, пока брокер не меняет часовые пояса, за исключением корректировки на летнее время, вы можете определить смещение относительно GMT как для текущего времени, так и для исторического. Если на прошлой неделе в стандартное время у брокера GMT+2, а в Лондоне GMT, то 8 утра по лондонскому времени будет 10 утра по времени сервера. В следующем месяце, при переходе на летнее время, когда брокер находится в GMT+3, а Лондон в GMT+1, 8 утра по лондонскому времени будет соответствовать 10 утра по серверному времени. Сегодня, когда брокер переходит на летнее время, а Лондон на стандартное, брокер - GMT+3, а Лондон - GMT, поэтому 8 утра по лондонскому времени будет соответствовать 11 утра по серверному времени.

Если брокер находится в GMT-5 (EST), а Лондон - в GMT, то 8 утра по лондонскому времени будет 3 утра по серверному времени.

 
gchrmt4:

Исторический калькулятор GMT сам по себе не представляет особой сложности (операционная система Windows уже содержит все необходимые данные), но это не главная проблема. Проблема в том, что вы можете определить текущее смещение между временем брокера и GMT, но не знаете, изменилось ли оно. На примере выше вы можете увидеть, что брокер в настоящее время находится на GMT+3 (предполагая, что часы на локальном компьютере точны...), но вы не знаете, что на прошлой неделе брокер находился на GMT+2.

Вполне возможно, что клиентский терминал МТ4 просто не имеет этой информации.

Если бы она у него была, то MT4 мог бы предоставить либо голые данные, которые вы могли бы обработать самостоятельно, либо функцию, которая позволила бы вам сказать "конвертировать любую дату брокера в прошлом в GMT". После этого вы могли бы использовать таблицу поиска (или Windows API) для преобразования исторического времени GMT в другой часовой пояс, например, Лондон. Однако было бы предпочтительнее, чтобы MT4 делал это за вас, например, с помощью пары функций, таких как следующая:

datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);

datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);


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

Другой подход, согласно этой странице , существует только 62 брокера MT4? Так что не будет слишком сложно иметь таблицу поиска для каждого брокера и их определение времени (основано ли оно на реальном часовом поясе или на комбинации, как у FXCM), а также включить исторические изменения (как у Alpari).

62 - это заниженная оценка, и у крупных брокеров серверы настроены на разные часовые пояса.
 

Thirteen:

Если на прошлой неделе в стандартное время брокер находится на GMT+2, а Лондон - на GMT,

Как, используя только ту информацию, которую предоставляет MT4, вы узнаете, что на прошлой неделе брокер был на GMT+2?
 

С точки зрения здравого смысла сервер MT4 должен был бы постоянно использовать GMT, но вы знаете, что они не собираются этого делать.

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