ロンドンブレイクアウト
フォーラムメンバーの皆様へ。
数週間前から、MQL4で先に進もうとしているのですが、なんというチャレンジでしょうか。私はすでに専門家であることを望んでいました！しかし、私はそうではないので、私は少し助けを得ることを望んでいます。
私はロンドンのオープニングセッションのためのブレイクアウトエキスパートアドバイザーを構築しようとしています。私は私の専門家の顧問は、ロンドンのオープン前に5つのバーの高値と安値を計算し、その後、高値と安値を計算したい。
この関数では、私はiHigh関数の高値とiLow関数の安値を使用して範囲を計算する必要があると仮定します。しかし、このレンジは一日の間に変化します。私はその範囲のこれらの高値と安値が可変ではなく、静的であることを望んでいます。
どなたかアイデアをお持ちの方はいらっしゃいませんか？
ありがとうございました。
ロンドン・オープンが始まるバーはどうやって見つけるんだ？
どのようにそれを行うかを示す
ロンドンがオープンするバーをどうやって探せばいいのかわからないんだ。
私はまだMQL4に慣れていないのです。
それとも、MQL4に組み込まれた日付/時刻関数は、この種のものにはまだ 不適切なのでしょうか？
2つの問題があります。
* ブローカーサーバーとGMTの間のオフセットを確実に取得することはできません。なぜなら、（a）夏時間で変わることがあり、（b）オフセットを計算するためにTimeCurrent（）とTimeGMT（）の比較は週末に失敗するからです。
* マーケットが開いている間、現在のオフセットを取得することができても、GMT時間をロンドンのような他のタイムゾーンに変換するビルトインの方法はありません。
言い換えると、(a) ブローカーのサーバーはCETで動作しているため、(b) 各バーのロンドン時間は、MT4が報告する時間より1時間遅れていると判断する方法は組み込まれていないのです。
それとも、MQL4に組み込まれた日付/時刻関数は、この種のものにはまだ 不適切なのでしょうか？
2つの問題があります。
* ブローカーサーバーとGMTの間のオフセットを確実に取得することはできません。なぜなら、（a）夏時間で変わることがあり、（b）オフセットを計算するためにTimeCurrent（）とTimeGMT（）の比較は週末に失敗するからです。
* マーケットが開いている間、現在のオフセットを取得することができても、GMT時間をロンドンのような他のタイムゾーンに変換するビルトインの方法はありません。
言い換えれば、(a) ブローカーのサーバーは CET で動作しており、したがって (b) 各バーのロンドン時間は、MT4 が報告する時間より 1 時間遅れていることを判断する内蔵方法はない。
TimeGMT() はサマータイムによって変化しないようです。 例えば、私は米国に住んでいるので、現在私のローカルタイムゾーンはEDTです。 私のブローカーのMT4サーバーは、現在、東部標準時です。 さて、次のコードとその出力について考えてみましょう。
Print ("1. GMT = ", TimeToString(TimeGMT())); Print ("2. Local Time (EDT) = ", TimeToString(TimeLocal())); Print ("3. Daylight Saving Adjustment: ", TimeDaylightSavings()/3600); Print ("4. GMTOffset for TimeLocal = ", TimeGMTOffset()/3600); Print ("5. Server Time (EEST) = ", TimeToString(TimeCurrent())); int local = (TimeLocal() - TimeGMT()) / 3600; int server = MathRound((TimeCurrent() - TimeGMT()) / 3600.0); string prt = "TimeLocal is "; if (local > 0) prt = StringConcatenate(prt, "GMT+", MathAbs(local)); else if (local < 0) prt = StringConcatenate(prt, "GMT-", MathAbs(local)); else prt = StringConcatenate(prt, "GMT"); prt = StringConcatenate(prt, " and TimeCurrent is "); if (server > 0) prt = StringConcatenate(prt, "GMT+", MathAbs(server)); else if (local < 0) prt = StringConcatenate(prt, "GMT-", MathAbs(server)); else prt = StringConcatenate(prt, "GMT"); Print (prt);
17:52:28 Expert TestEA-1 EURUSD,H1: 正常にロードされました。
17:52:28 TestEA-1 EURUSD,H1: 1. GMT = 2014.03.11 21:52
17:52:28 TestEA-1 EURUSD,H1: 2.現地時間(EDT)=2014.03.11 17:52です。
17:52:28 TestEA-1 EURUSD,H1: 3.サマータイム調整: -1
17:52:28 TestEA-1 EURUSD,H1: 4. GMTOffset for TimeLocal = 4
17:52:28 TestEA-1 EURUSD,H1: 5.サーバー時間(EEST) = 2014.03.12 00:52
17:52:28 TestEA-1 EURUSD,H1: TimeLocalはGMT-4、TimeCurrentはGMT+3です。
上のGMTの時間とロンドンの時間を確認したところ、同じでした（ロンドンは3月末までBSTに変わりません）。 なので、TimeGMT()は現地の夏時間調整を加えずにGMTを返しているのだと思います。 EDTは UTC-4、EESTは UTC+3と定義されています。
また、米国やEUのサマータイムの開始と終了を判断する必要がある場合は、以下の関数を参照して ください。
私は上記のGMT時間をロンドンのそれと確認しました[...]。
ほぼご存知と思いますが・・・問題の一つは、ブローカーの時刻とGMTのオフセットが、（a）サマータイムによって変動する場合としない場合があり、（b）変動するかどうかはMT4が提供する情報だけでは判断できないことです。これらの機能を 詳しく見たわけではありませんが、MT4が提供する情報だけではそのような計算ができないことは同意できるかと思います。
私が見る限り、4月の初めには、上記のコードはブローカーがGMT+4であると言い始めるでしょう。私が言いたいのは、前の週にブローカーがGMT+3であったことをMT4から知る方法はなく、特定のGMT時間またはGMT時間のオフセットでの価格活動を計算したい場合、iBarShift()などの使用はそれに応じて調整する必要があるかもしれない、ということです。
ところで、もしあなたが今日上記のコードを実行したなら、あなたのブローカーはほぼ間違いなく東部標準時を使用することはできません。3月30日まではEETであるべきです。もし現在GMT+3であれば、EEST以外を使用していることになります。(リンク先のページには「この時期、EESTにある場所はEETになりました」とあります)。
gchrmt4:
.. .
ところで、今日、上記のコードを実行した場合、あなたのブローカーは、ほぼ確実にEESTにすることはできません。彼らは3月30日までEETであるべきです。もし、現在GMT+3であれば、東部標準時以外を使用していることになります。(リンク先のページには「この時期、EESTにある場所はEETになりました」と書いてあります）。
私のブローカーは、ニューヨークの午後5時に対応するために、MT4サーバーのタイムゾーンをGMT+2からGMT+3に変更 しますが、これは米国が夏時間に変更するのと同じタイミングで行われ、2014年3月9日にそうなっています。 ヨーロッパでは、GMT+2が標準時のEETにほぼ対応し、GMT+3が夏時間のEESTに対応する。 例えば、欧州の時間帯を 参照してください。 つまり、ご覧の通り、私のローカルタイムゾーンがEDTで、ブローカーのタイムゾーンがEESTに対応しているときに、今日コードを実行したことは間違いないのです。
[1] 私が見る限り、4月の初めには、上記のコードはブローカーがGMT+4であると言い始めるでしょう。
[2] 私が言いたいのは、前の週にブローカーがGMT+3であったことをMT4から知る方法はなく、特定のGMT時間またはGMT時間のオフセットでの価格活動を調べたい場合、iBarShift()などの使用はそれに応じて調整する必要があるかもしれない、ということです。
1.なぜ4月にGMT+4が返されるのですか？私のローカルコンピュータの時間はすでにサマータイムに調整されていますし、私のブローカーはすでにサマータイムを反映するようにサーバーを調整しています。
2.ブローカーがサマータイムを反映させるために時間を変更する可能性があり、その場合、GMTへのオフセットが変更されます。 しかし、その変化を予測することは可能です。 例えば、サマータイムの開始と終了の日時は年によって変わりますが、その変化は予測可能であり、それゆえプログラム可能なのです。 ルールをコード化するだけだ。 しかし、TimeGMT()はローカルタイムゾーン、ブローカタイムゾーン、サマータイムオフセットに関係なく、GMTを返す必要があります。
ご存知のように、ブローカーの時刻とGMTのオフセットは、(a)夏時間によって変化する可能性があり、(b)変化するかどうかは、MT4が提供する情報に基づいて決定できないことが、問題の1つとなっています。これらの機能を詳しく見たわけではありませんが、MT4が提供する情報だけでは、そのような計算はできないということで一致しているのではないでしょうか。
もしブローカーがサマータイムを調整すれば、その調整によってGMTへのオフセットが変化しますが、上記のように、その変化を予測して調整することは可能です。 また、ある場所（例えば、ロンドン）が夏時間を調整する場合、ローカルルールをコード化することで、その変更を予測し、調整することができます。
もしブローカーがサマータイムを調整すれば、その調整によってGMTへのオフセットが変わりますが、上に述べたように、その変化を予測し、調整することができます。 また、ある場所（例えばロンドン）がサマータイムを調整した場合、ローカルルールをコード化することで、その変化を予測し、調整することも可能です。
しかし、MT4が提供する情報だけでは、その変化を予測することはできません。MT4に「ロンドンでのxに相当する時間を教えてください」と言うのではなく、ロンドンGMTの「ローカルルールをコード化」する必要があります。
GMT+3というサーバーの時刻は、EESTがGMT+3であるという意味ではEESTに相当するかもしれませんが、Wikipediaとworldclock.comによると、EESTはまだどこもやっていないはずです。その変更は3月30日まで起こらないはずだ。キプロス、ギリシャ、イスラエルなどの現在の時刻は GMT+2である。
したがって、ブローカーはGMT+2でサーバーを動かし、ヨーロッパの日付ではなく、アメリカの日付で夏時間に変更しているのでしょう。これはEET/EESTとは違う。(そして、ブローカーが使用する時間設定についてユーザーに何らかの入力を求めることなく、時間と日付を自動的に調整するコードを書くことができるという点で、これはさらに予測不可能です)。
したがって、ブローカーが最近 GMT+2 から GMT+3 に変更され、GMT+3 から GMT+4 に変更されようとしていない場合、ブローカー時間と GMT 間の現在の オフセットを米国の時間変更の前の先週のバーに適用しようとすると、それは間違っているということです。今週は、ブローカーのバーがロンドンより3時間進んでいます。先週は2時間進んでいました。(この3時間のオフセットを使って、先週のロンドン時間午前8時の価格を求めると、間違った答えになります。
私が言いたいのは、MT4自体から得られる情報、つまりブローカー時間とGMTの現在のオフセットは、「先週の水曜日のロンドンの始値を計算する」というようなことをするには、実際には不十分であるということです。
MT4は、どのようにすれば、そのようなことができるようになるのでしょうか？ 私はあなたのことを知らないが、私は確かに地域の歴史的なGMTオフセット計算機を作成する作業を楽しむことはありません。想像してみてください(・ω・)ノもし作ったら、市場に出しますので、皆さん、大枚はたいてください(笑)。
冗談です、そんなもの作ろうとは思っていません。しかし、WHRはそれを行うことができます、私は彼がすでに持っているに違いない。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
フォーラムメンバーの皆様へ。
数週間前から、MQL4で先に進もうとしているのですが、なんというチャレンジでしょうか。私はすでに専門家であることを望んでいました！しかし、私はそうではないので、私は少し助けを得ることを望んでいます。
私はロンドンのオープニングセッションのためのブレイクアウトエキスパートアドバイザーを構築しようとしています。私は私の専門家の顧問は、ロンドンのオープン前に5つのバーの高値と安値を計算し、その後、高値と安値を計算したい。
この関数では、私はiHigh関数の高値とiLow関数の安値を使用して範囲を計算する必要があると仮定します。しかし、このレンジは一日の間に変化します。私はその範囲のこれらの高値と安値が可変ではなく、静的であることを望んでいます。
どなたかアイデアをお持ちの方はいらっしゃいませんか？
ありがとうございました。