datetime EndTrading;
if(TimeDayOfWeek(TimeCurrent())==5) // если сейчас пятница, например возьмем сегодняшний день, первый тик 2014.11.07 00:00
EndTrading=StringToTime("21:30"); // подразумевается что тут должно быть время пятницы...if(TimeDayOfWeek(TimeCurrent())==5) // если настала пятницаif(TimeCurrent()>EndTrading) // и время удовлетворяет условиюPrint("Настала пятница и текущее время больше чем 21:30");
datetime EndTrading;
if(TimeDayOfWeek(TimeCurrent())==5) // если сейчас пятница, от текущего времени. Наступит когда по времени сервера будет 00:00
EndTrading=StringToTime("21:30"); // А тут в 00:00 устанавливается четверг 21:30 потому, что это время пятницы ещё далеко.
if(TimeDayOfWeek(TimeCurrent())==5) // если настала пятницаif(TimeCurrent()>EndTrading) // А тут условие если(текущее время больше чем четверг 21:30)
{
Print("EndTrading = ", TimeToString(EndTrading)); // Посмотри что будет напечатано.
}
そして、このコードは正しく動作します。
if(TimeDayOfWeek(TimeCurrent()) == 5 && TimeCurrent() >= StringToTime("21:30"))
Print("Настала пятница и текущее время больше чем 21:30");
if(TimeDayOfWeek(TimeCurrent())==5) // если сейчас пятница, от текущего времени. Наступит когда по времени сервера будет 00:00
EndTrading=StringToTime("21:30"); // А тут в 00:00 устанавливается четверг 21:30 потому, что это время пятницы ещё далеко.
その答えにすぐには気付けなかったのです。そうですね......正直なところ、「迷いがない」とおっしゃる意味がよく分かりませんでした。
StringToTime()が経過秒数をカウントするのは、どのような時なのか？
この関数は、基本的に完全に左寄りの日付（ローカルPCの日付は左寄りだと思います）を取り、ブローカーのサーバーの現在時刻と比較するのですが、なぜそれが重要ではないのでしょうか？
上のスクリーンショットから、ローカルPCの時刻がブローカーの時刻より1時間進んでいる、つまりGMTシフトが大きくなっているというコメントがあります。もし、X時間少なかったら、金曜日に書いたケースのように、致命的だ。
取引終了時間については。StringToTime() 関数では、ブローカーがいつ取引を終了するかは関係ない はずなのですが...。
それ以外に説明がつかない。
モスクワが11時40分なら、1970年01月01日から現在までの 経過時間はXXX秒。
例えばロンドンで11時40分になるとき、今のモスクワと同じ秒数になる...。これは、ロンドンでの1970年1月1日が現在よりずっと遅かったからに他なりません。指定時間ではなく、あくまで秒数です。
1970年01月01日00時00分00秒からの秒数を計算する数式を自分で書いてみてください。
短期間であれば、この計算式を使うこともできます。当月の初めから、6*24*60*60 + 11*60*60 + 59*60 + 現在見ている時計の秒の値 を経過。
もちろん、70年からの経過秒数で比較するのだが、この秒数には日付と時間、すべてが加味されている。
私が最近遭遇した問題を単純化したものですが、一例を挙げましょう。
当初、私はそのような解決策を考えていました。
そして、今度はギミックです。コードで指定したプリントは、金曜日にポップアップしますが、21:30以降ではなく、最初のティックの00:00にポップアップします。
ブローカーのサーバーが金曜日になったとき、私のローカルPCではまだ木曜日だったので、タイムシフトが違うのです。
テスターでは、すべて問題なく、金曜日の21:30以降に本来のプリントを出すことができます。紛らわしくないですか？
もちろん、70年からの経過秒数で比較するのだが、この秒数には日付と時間、すべてが加味されている。
一例を挙げると、基本的には私が最近遭遇した問題を単純化したものです。
当初、私はそのような解決策を考えていました。
そして、今度はギミックです。コードで指定したプリントは、金曜日にポップアップしますが、21:30以降ではなく、最初のティックの00:00にポップアップします。
ブローカーのサーバーが金曜日になったとき、私のローカルPCではまだ木曜日だったので、タイムシフトが違うのです。
テスターでは、すべて問題なく、金曜日の21:30以降に本来のプリントを出すことができます。紛らわしくないですか？
もちろん、混乱はしますよ。頭の中が混乱するだけです。TimeToString("21:30") は、現在の日付が21:30:00から翌日の21:29:59までとなる。コードのコメントを訂正しておきます。
そして、このコードは正しく動作します。
同じノートパソコンに、小数点以下4桁のMT4端末と小数点以下5桁のMT4端末があります。同時に1台目のトラフィックは105/0kb、2台目のトラフィックは3450/0kbとなります。1つ目は6％、2つ目は39％のCPU負荷がかかっています。何が問題なのか？これって、当たり前なんでしょうか？
アレクセイビク
パソコンの日付を2000年に変更。
はこのスクリプトを実行した。
で、これを得た。
したがって、StringToTime()はローカルコンピュータから日付を取得します。
アレクセイビク
パソコンの日付を2000年に変更。
はこのスクリプトを実行した。
で、これを得た。
そこで、StringToTime() は、ローカルコンピュータから日付を取得します。
それがどうした？この整数値は、必要な時間の1970年1月1日から経過した秒数と比較します。
この行を確認した方が良い
問題が発生した場所今日は金曜日。
その行を確認した方がいい
問題が発生した場所今日は金曜日。
確認したところ、ローカルコンピュータの日付がブローカーの日付より低ければ、プリンターがあるのだそうです。
で、ローカルコンピュータの日付がブローカーより大きい場合、プリンターはありません。
同時に、確実に経過している時間、つまり「11:30」を確認しました。
の場合、TimeCurrent() は2014.11.06 11:30と 比較され、2番目の場合、2014.11.0811:30 と比較されます。
追記 ハイライトを修正しました
1行目のコメントは明確ですが、2行目のコメントは明確ではありません。
もう金曜日は来ているのに、なぜ遠いのでしょう？結局、2行目は金曜日の場合のみ実行されます。
確認したところ、ローカルコンピュータの日付がブローカーの日付より低ければ、プリンターがあることになります。
で、ローカルコンピュータの日付がブローカーの日付より高ければ、プリンターは存在しないことになります。
すなわち、時間が経過したこと、すなわち「11:30」である。
の場合、TimeCurrent()は2014.11.06 11:30と 比較され、2番目の場合、2014.11.0811:30 と比較されます。
追記 ハイライトを修正しました
ここでは、ローカルタイムが サーバータイムより1時間長くなっています。
このスクリプト
以下の値を出力する。
まず1970年01月01日から指定時刻までの経過秒数、次に通常の形式の時刻を表示します。
そのうえで、これらの価値観の何があなたを混乱させるのかを説明してください。
そうですね、2回目のコメントでは、別のことを考えていました。
да.
こんにちは。
こんなタスクがあるんです。(ティックに添付することができません）。
保留中の注文が トリガーされた場合{then...}。
私のEAでは、Terminal.mqhを使って注文の計算をしています。
ターミナル // Mas_Tip[0]オープン 買い
// 買い注文の数が1つ 増えた場合
if (Mas_Tip[0]+1)
{
機能
}
すべてがうまくいく。しかし、次のティックごとにトリガーされます。
このケースをダニに付けるには？そして、前のティックと与えられたティックの値を比較します。