ロンドンブレイクアウト - ページ 2 123 新しいコメント ydrol 2014.03.12 18:45 #11 そう、すべてIMOの不可解な設計上の決定の せいなのです。） ですから、サーバーの時刻は、1年を通じて世界のどの時計とも一致しないかもしれません。 私は、特にバックテスト中にGMT時間を正確に決定する方法を1つ持っています。この方法は、以下のようなブローカーに有効なようです。 ヒストリカルデータの途中で夏時間を変更した（Alpari）。 またはThirteenが指摘するように、タイムゾーンに対して非標準の夏時間を使用している(FXCM)。 しかし、この方法は私には少しハッキングのように感じられます。 それは、他のソース（デューカスコピー）からGMTベースの相場をダウンロードし、毎日の高値の時間を比較することを含んでいました。バックテストでは問題ないのですが、現在は手動で1時間のデータをダウンロードし、高値をフィルタリングしています（perlスクリプトを使用）。 少なくとも2つのソースからGMT時間帯のH1クォートを自動的に取得できるようになれば、この方法が私の目的にとって快適なものになるでしょう。 gchrmt4 2014.03.12 18:52 #12 SDC: MT4は、どのようにすれば、そのようなことができるようになるのでしょうか？ 私はあなたのことを知らないが、私は確かに地域の歴史的なGMTオフセット計算機を作成する作業を楽しむことはありません。想像してみてください(・ω・)ノもし作ったら、市場に出しますので、皆さん、大枚はたいてください(笑)。 歴史的なGMT計算機自体は特に難しいものではありません(Windowsオペレーティングシステムには必要なデータがすべて含まれています)が、主要な問題ではありません。問題は、ブローカータイムとGMTの現在のオフセットを決定することはできますが、それがいつ変更されたかどうかがわからないことです。上記の例では、ブローカーは現在GMT+3であることがわかりますが（ローカルコンピュータの時計が正確であると仮定して...）、ブローカーが先週GMT+2であったことはわかりません。 MT4クライアントターミナルがこの情報を持っていない可能性が非常に高いです。 もし持って いれば、MT4は、あなたが自分で処理できるようなデータを提供するか、あるいは、「過去のブローカーの日付をGMTに変換する」機能を 提供できるはずです。それができれば、ルックアップテーブル（またはWindows API）を使って、過去のGMT時間をロンドンなどの他のタイムゾーンに変換することができます。しかし、MT4がこれをも行ってくれることが望ましい。例えば、以下のような関数の組を使用する。 datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone); datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone); gchrmt4 2014.03.12 18:55 #13 ydrol: そう、すべてはIMOの不可解な設計上の判断 のためなのです :) (UTCに固定しない理由は、ブローカーがEETで週に5つのD1ローソクを与えて実行できるように、GMTZを使用するブローカーでD1 ATRなどのシステム的な過小評価につながる6番目の小さなローソクを避けるためだと推測しています). ydrol 2014.03.12 19:04 #14 gchrmt4: (UTCに固定しない理由は、ブローカーがEETで週5本のD1ローソク足を出し、GMTZを使うブローカーでD1 ATRなどのシステム的な過小評価につながる6番目の小さなローソク足を避けるためだと推測されます)。 私はそのようなものをすべてクライアントに入れたのですが、そのせいでクライアントがいろいろなところで複雑になっています :)しかし、少なくともすべての変数がわかっているのです。 ydrol 2014.03.12 19:07 #15 別のアプローチとして、このページに よると、MT4ブローカーは62社しかないのですね。だから、各ブローカーと時間の定義（実際のタイムゾーンに基づくか、FXCMのような組み合わせか）のルックアップテーブルを持ち、さらに（Alpariのように）過去の変化を組み込むことはそれほど難しくないでしょう。 これはおそらく最も堅牢な方法であり、ブローカーが顧客をもう少し混乱させたいと思うたびに微調整が必要になるでしょう。） GreenMoney 2014.03.12 19:09 #16 gchrmt4: [1] あなたのサーバーの時間であるGMT+3は、EESTがGMT+3であるという意味でEESTに対応するかもしれませんが、Wikipediaとworldclock.comの両方によると、EESTにはまだ誰もいないはずです。その変更は3月30日まで起こらないはずだ。キプロス、ギリシャ、イスラエルなどの現在の時刻はGMT+2である。 [2] したがって、ブローカーはGMT+2でサーバーを動かしているが、ヨーロッパの日付ではなく、アメリカの日付で夏時間に変更しているのでしょう。 [3] これはEET/EESTと同じではありません。(そして、ブローカーがどの時間設定を使うかについてユーザーに何らかの入力を求めることなく、時間と日付を自動的に調整するコードを書くことができるという点では、さらに予測不可能です)。 その通りです。 正しい。 EETはGMT+2ですが、GMT+2はEETだけではありません。 また、EESTはGMT+3ですが、GMT+3はEESTだけではありません。 私のブローカーのタイムゾーンをEET/EESTと記述したのは、特にこのスレッドではロンドンブレイクアウトを議論しているので、標準時の間はGMT+2、夏時間の間はGMT+3であると推測しただけのつもりでした。 私の説明が混乱を招いたのなら謝ります :) したがって、ブローカーがGMT+3からGMT+4に変更されようとしているのではなく、GMT+2からGMT+3に最近変更された場合、米国の時計が変更される前の先週のバーに適用しようとすると、ブローカー時間とGMT間の現在のオフセットが間違っていることを意味するものである。今週は、ブローカーのバーがロンドンより3時間進んでいます。先週は2時間進んでいました。(この3時間のオフセットを使って、先週のロンドン時間午前8時の価格を求めると、間違った答えが返ってきます。 ブローカーは一般的に、サマータイムを調整する以外、サーバーのタイムゾーンを頻繁に変更することはありません。 サマータイム調整のために、私は任意の日付/時間（1987年（米国）、1996年（EU）から2020年以降まで）を使用して、米国とEUについて、サマータイム開始日とサマータイム終了日を計算することができます。 このコードがあれば、あとは現在のオフセットを GMT に合わせて、見ている時間のサマータイムに対応するように調整するだけです。 ビルド600+で新しく追加されたTimeGMT()を使って、ブローカーのGMTに対する現在の オフセットを計算します。 しかし、ブローカーのタイムゾーンを過去から判断することは（私の知る限りでは）できません。 例えば、あるブローカーがサーバーのタイムゾーンを標準時のGMTから標準時のGMT+2へ変更したことがあります。 履歴データはすべてGMT+2ではなくGMTであったため、切り替え前の時間のオフセットをハードコーディングすることで対処しました（GMT+2を反映するために履歴を修正したくはなかったのです）。 その点では、あなたと私は同意見だと思います。 ブローカーが単にタイムゾーンを変更しない限り（サマータイムを調整する以外）、GMTへのオフセットを計算し、そのオフセットをサマータイム用に調整することは可能なはずです。 私が言いたいのは、MT4自体から得られる情報（ブローカー時間とGMTの現在のオフセット）は、「先週水曜日のロンドンの始値を計算する」というようなことを行うには、実際には不十分であるということです。 私はあなたの意見に反対だと思います。 ブローカーがタイムゾーンを変えない限り、夏時間の調整を除いて、現在時刻と 過去時刻の両方でGMTへのオフセットを決定することができます。 例えば、先週、標準時でブローカーがGMT+2、ロンドンがGMTの場合、ロンドン時間の午前8時はサーバー時間の午前10時となります。 来月、夏時間の間に、ブローカーがGMT+3、ロンドンがGMT+1の場合、ロンドン時間の午前8時はサーバー時間の午前10時に対応します。 今日、ブローカーが夏時間でロンドンが標準時のとき、ブローカーはGMT+3、ロンドンはGMTなので、ロンドン時間午前8時はサーバー時間午前11時に相当します。 ブローカーがGMT-5（東部標準時）、ロンドンがGMTである場合、ロンドン時間午前8時はサーバー時間午前3時です。 Ian Venner 2014.03.12 19:10 #17 gchrmt4: GMTの履歴を計算すること自体は特に難しいことではありませんが（Windowsオペレーティングシステムには必要なデータがすべて含まれています）、主要な問題ではありません。問題は、ブローカー時刻とGMTの現在のオフセットを決定することはできますが、それがいつ変更されたかを知らないということです。上記の例では、ブローカーは現在GMT+3であることがわかりますが（ローカルコンピュータの時計が正確であると仮定して...）、ブローカーが先週GMT+2であったことはわかりません。 MT4クライアントターミナルがこの情報を持っていない可能性が非常に高いです。 もし持って いれば、MT4は、あなたが自分で処理できるようなデータを提供するか、あるいは、「過去のブローカーの日付をGMTに変換する」機能を提供できるはずです。それができれば、ルックアップテーブル（またはWindows API）を使って、過去のGMT時間をロンドンなどの他のタイムゾーンに変換することができます。しかし、MT4がこれをも行ってくれることが望ましい。例えば、以下のような関数の組を使用する。 datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone); datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone); たしかにサマータイムがなければ難しくないのですが、あるんです(笑)コーディングするのが悪夢になりそうです。歴史的な異常がいたるところにあります。使用するタイムゾーンを変更した地域、夏時間をまったく使用しない実験をしてから夏時間に戻した地域、ある場所では夏時間を尊重するが他の場所では尊重しない地域、考慮すべき異常が世界中にたくさんあるのです......。 gchrmt4 2014.03.12 19:12 #18 ydrol: 別のアプローチとして、このページに よると、MT4ブローカーは62社しかないのですね。各ブローカーと時間の定義（実際のタイムゾーンに基づくか、FXCMのような組み合わせか）のルックアップテーブルを持ち、さらに（Alpariのような）過去の変更を組み込むことはそれほど難しくないでしょう。 62は過小評価であり、大きなブローカーは異なるタイムゾーンに設定されたサーバーを持っています。 gchrmt4 2014.03.12 19:13 #19 Thirteen: 標準時の先週、ブローカーが GMT+2 で、ロンドンが GMT であった場合。 MT4が提供する情報だけで、ブローカーが先週GMT+2であったことをどのようにして知ることができますか？ Ian Venner 2014.03.12 19:26 #20 MT4サーバーがGMTを常に使用するのが常識的なアプローチだが、そんなことはしないのは分かっているはずだ。 123 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
そう、すべてIMOの不可解な設計上の決定の せいなのです。） ですから、サーバーの時刻は、1年を通じて世界のどの時計とも一致しないかもしれません。
私は、特にバックテスト中にGMT時間を正確に決定する方法を1つ持っています。この方法は、以下のようなブローカーに有効なようです。
しかし、この方法は私には少しハッキングのように感じられます。
それは、他のソース（デューカスコピー）からGMTベースの相場をダウンロードし、毎日の高値の時間を比較することを含んでいました。バックテストでは問題ないのですが、現在は手動で1時間のデータをダウンロードし、高値をフィルタリングしています（perlスクリプトを使用）。
少なくとも2つのソースからGMT時間帯のH1クォートを自動的に取得できるようになれば、この方法が私の目的にとって快適なものになるでしょう。
MT4は、どのようにすれば、そのようなことができるようになるのでしょうか？ 私はあなたのことを知らないが、私は確かに地域の歴史的なGMTオフセット計算機を作成する作業を楽しむことはありません。想像してみてください(・ω・)ノもし作ったら、市場に出しますので、皆さん、大枚はたいてください(笑)。
歴史的なGMT計算機自体は特に難しいものではありません(Windowsオペレーティングシステムには必要なデータがすべて含まれています)が、主要な問題ではありません。問題は、ブローカータイムとGMTの現在のオフセットを決定することはできますが、それがいつ変更されたかどうかがわからないことです。上記の例では、ブローカーは現在GMT+3であることがわかりますが（ローカルコンピュータの時計が正確であると仮定して...）、ブローカーが先週GMT+2であったことはわかりません。
MT4クライアントターミナルがこの情報を持っていない可能性が非常に高いです。
もし持って いれば、MT4は、あなたが自分で処理できるようなデータを提供するか、あるいは、「過去のブローカーの日付をGMTに変換する」機能を 提供できるはずです。それができれば、ルックアップテーブル（またはWindows API）を使って、過去のGMT時間をロンドンなどの他のタイムゾーンに変換することができます。しかし、MT4がこれをも行ってくれることが望ましい。例えば、以下のような関数の組を使用する。
datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);
datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);
そう、すべてはIMOの不可解な設計上の判断 のためなのです :)
(UTCに固定しない理由は、ブローカーがEETで週5本のD1ローソク足を出し、GMTZを使うブローカーでD1 ATRなどのシステム的な過小評価につながる6番目の小さなローソク足を避けるためだと推測されます)。
私はそのようなものをすべてクライアントに入れたのですが、そのせいでクライアントがいろいろなところで複雑になっています :)しかし、少なくともすべての変数がわかっているのです。
別のアプローチとして、このページに よると、MT4ブローカーは62社しかないのですね。だから、各ブローカーと時間の定義（実際のタイムゾーンに基づくか、FXCMのような組み合わせか）のルックアップテーブルを持ち、さらに（Alpariのように）過去の変化を組み込むことはそれほど難しくないでしょう。
これはおそらく最も堅牢な方法であり、ブローカーが顧客をもう少し混乱させたいと思うたびに微調整が必要になるでしょう。）
gchrmt4:
[1] あなたのサーバーの時間であるGMT+3は、EESTがGMT+3であるという意味でEESTに対応するかもしれませんが、Wikipediaとworldclock.comの両方によると、EESTにはまだ誰もいないはずです。その変更は3月30日まで起こらないはずだ。キプロス、ギリシャ、イスラエルなどの現在の時刻はGMT+2である。
[2] したがって、ブローカーはGMT+2でサーバーを動かしているが、ヨーロッパの日付ではなく、アメリカの日付で夏時間に変更しているのでしょう。
[3] これはEET/EESTと同じではありません。(そして、ブローカーがどの時間設定を使うかについてユーザーに何らかの入力を求めることなく、時間と日付を自動的に調整するコードを書くことができるという点では、さらに予測不可能です)。
ブローカーは一般的に、サマータイムを調整する以外、サーバーのタイムゾーンを頻繁に変更することはありません。 サマータイム調整のために、私は任意の日付/時間（1987年（米国）、1996年（EU）から2020年以降まで）を使用して、米国とEUについて、サマータイム開始日とサマータイム終了日を計算することができます。 このコードがあれば、あとは現在のオフセットを GMT に合わせて、見ている時間のサマータイムに対応するように調整するだけです。
ビルド600+で新しく追加されたTimeGMT()を使って、ブローカーのGMTに対する現在の オフセットを計算します。 しかし、ブローカーのタイムゾーンを過去から判断することは（私の知る限りでは）できません。 例えば、あるブローカーがサーバーのタイムゾーンを標準時のGMTから標準時のGMT+2へ変更したことがあります。 履歴データはすべてGMT+2ではなくGMTであったため、切り替え前の時間のオフセットをハードコーディングすることで対処しました（GMT+2を反映するために履歴を修正したくはなかったのです）。 その点では、あなたと私は同意見だと思います。 ブローカーが単にタイムゾーンを変更しない限り（サマータイムを調整する以外）、GMTへのオフセットを計算し、そのオフセットをサマータイム用に調整することは可能なはずです。
私が言いたいのは、MT4自体から得られる情報（ブローカー時間とGMTの現在のオフセット）は、「先週水曜日のロンドンの始値を計算する」というようなことを行うには、実際には不十分であるということです。
私はあなたの意見に反対だと思います。 ブローカーがタイムゾーンを変えない限り、夏時間の調整を除いて、現在時刻と 過去時刻の両方でGMTへのオフセットを決定することができます。 例えば、先週、標準時でブローカーがGMT+2、ロンドンがGMTの場合、ロンドン時間の午前8時はサーバー時間の午前10時となります。 来月、夏時間の間に、ブローカーがGMT+3、ロンドンがGMT+1の場合、ロンドン時間の午前8時はサーバー時間の午前10時に対応します。 今日、ブローカーが夏時間でロンドンが標準時のとき、ブローカーはGMT+3、ロンドンはGMTなので、ロンドン時間午前8時はサーバー時間午前11時に相当します。
ブローカーがGMT-5（東部標準時）、ロンドンがGMTである場合、ロンドン時間午前8時はサーバー時間午前3時です。
GMTの履歴を計算すること自体は特に難しいことではありませんが（Windowsオペレーティングシステムには必要なデータがすべて含まれています）、主要な問題ではありません。問題は、ブローカー時刻とGMTの現在のオフセットを決定することはできますが、それがいつ変更されたかを知らないということです。上記の例では、ブローカーは現在GMT+3であることがわかりますが（ローカルコンピュータの時計が正確であると仮定して...）、ブローカーが先週GMT+2であったことはわかりません。
MT4クライアントターミナルがこの情報を持っていない可能性が非常に高いです。
もし持って いれば、MT4は、あなたが自分で処理できるようなデータを提供するか、あるいは、「過去のブローカーの日付をGMTに変換する」機能を提供できるはずです。それができれば、ルックアップテーブル（またはWindows API）を使って、過去のGMT時間をロンドンなどの他のタイムゾーンに変換することができます。しかし、MT4がこれをも行ってくれることが望ましい。例えば、以下のような関数の組を使用する。
datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);
datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);
たしかにサマータイムがなければ難しくないのですが、あるんです(笑)コーディングするのが悪夢になりそうです。歴史的な異常がいたるところにあります。使用するタイムゾーンを変更した地域、夏時間をまったく使用しない実験をしてから夏時間に戻した地域、ある場所では夏時間を尊重するが他の場所では尊重しない地域、考慮すべき異常が世界中にたくさんあるのです......。
別のアプローチとして、このページに よると、MT4ブローカーは62社しかないのですね。各ブローカーと時間の定義（実際のタイムゾーンに基づくか、FXCMのような組み合わせか）のルックアップテーブルを持ち、さらに（Alpariのような）過去の変更を組み込むことはそれほど難しくないでしょう。
Thirteen:
標準時の先週、ブローカーが GMT+2 で、ロンドンが GMT であった場合。
MT4サーバーがGMTを常に使用するのが常識的なアプローチだが、そんなことはしないのは分かっているはずだ。