私は完全に迷子になった - ページ 4 12345 新しいコメント Simon Gniadkowski 2014.02.12 16:42 #31 ydrol: datetimeのタイムゾーン(1970年からの秒数)は、UTCを基準にしています。UnixTimeと同じです。これは、UnixTime - 64 bit unix time です。 datetime - datetime = long (秒の長さ) datetime +/- seconds(long) = datetime(別の日付) datetime +/- seconds(int) = datetime(別の日付) GMT（グリニッジ標準時）の時刻を指定するにはどうすればよいですか？ William Roeder 2014.02.12 17:14 #32 ydrol: datetime (seconds past 1970) のタイムゾーンはUTCを基準にしています。 誤りです。タイムゾーンはブローカーのサーバーの時間です。あなたが使っているブローカーによります。 FMIC: あなたこそトロールです!これがこのスレッドでの私の最後の投稿ですあなたは努力する価値がありません。荒らしに餌を与えないでください。 あなたが反応すると、あなたは荒らしに力を与えてしまいます。あなたが荒らしを無視すると、荒らしは注意を引くために飢え、やがて死にます。 Ubzen 2014.02.12 17:26 #33 FMIC:あなたがこのトロールですこのスレッドへの投稿はこれが最後だ!あなたは努力する価値がありません。 私は、あなたが素晴らしい貢献をしてきたと思います。あなたの投稿は簡潔で、よく教えてくれるし、あなたの努力に対してたくさんの「ありがとう」のレスをもらっている。 ええ、あなたはこの人のためにできることはすべてやったと思います。 ydrol 2014.02.12 17:26 #34 あ、そうそう、mqlでは、タイムゾーンは時間を取得した場所に依存します。 ydrol 2014.02.12 17:32 #35 RaptorUK: GMT（グリニッジ標準時）の時刻を指定するにはどうすればよいですか？ mql4 は壊れた時間の概念を使っていることを忘れていました。それゆえ、ブローカー、コンピュータ、バックテストなど複数のソースが存在するため、すべての問題が発生するのです。 Simon Gniadkowski 2014.02.12 17:45 #36 ydrol: mql4は壊れた時間の概念を使っていることを忘れていました。タイムゾーンはどこから来たかに依存します。したがって、ブローカー、コンピュータ、バックテストなど複数のソースがあるため、すべての問題が発生します。 私は、あなたが修辞的な質問を受けたことを嬉しく思います。 削除済み 2014.02.12 19:03 #37 データ型促進ルールがそのように作用するのかと心配になりました。OK、では。 datetime - datetime = long (秒の長さ) datetime +/- seconds(long) = datetime(別の日付) datetime +/-秒(int) = datetime(別の日付) しかし、もし私が X=Y-Z とか (Y-Z)/60 とか言った場合、X はすでに long か int として宣言されていて、Y と Z は datetime ですが、これはとても、とても悪いことでしょうか？もしそうなら、static_castですべて解決するのでしょうか？ Raptorukさん、タイムゾーンに依存しないのです。もちろん、午後2時と午後3時の差は、どのタイムゾーンでも3600です。しかし、金曜日の 東部時間午後5時に取引が停止することが分かっていても、時間0（1970年1月1日の午前0時）がどのタイムゾーンにあるか分からない場合はどうでしょうか？そうすると、問題がありますね。1970年1月1日は木曜日でしたね。もし、タイム0がGMTであれば、その46時間後、つまり604800をモジュレーションした165600で取引が停止することになります。つまり、1週間が604800秒なので、604800で割った余りをX%604800の算術演算で計算し、165600で取引が停止するのです。しかし、ブローカーがそれより2タイムゾーン東にあり、彼らのジャンクが7200高いタイムスタンプを持つ場合、time%604800が165600ではなく、172800で取引が停止されるのです。 報告された時間インデックスについて不確実性があるように見えます。私は、私のコードに、取引が開始され停止される604800のモジュロの時間を計算させなければならないと思います、念のため。iTime('USDJPY',60,X)のようなものを調べて、48時間のギャップを見つけようと思っているんだ。iTimeは "open "時間、つまり1時間の始まりの時間であることは間違いないですよね？つまり、2日間のギャップの前の最後のタイムインデックスの1時間後に取引が停止し、ギャップ後の最初のタイムインデックスの始まりで正確に再開し、604800の倍数を追加すると、単に週を変更します。しかし、もしある週で最後の1時間が欠落していたり、最初の1時間が欠落していたらどうするのか、というような複雑な問題が追加されるでしょう。iTime('USDJPY',1,X)を使って、せいぜい分単位でずれるようにすればいいかもしれない。 おお、すごい、たくさんの投稿がこの一件で一気に加速しましたね。他の人にもわかるように、結局raptorukは大丈夫なんだろうけど、罵詈雑言は歓迎されないから、ydrolとかraptorukとか新しいことを言う人でないなら投稿をやめればいい、私はあなたの感情状態を一方的に気にしないから荒らしじゃないし、もし何かもっとなげかけたいことがあるなら耳に入らないことをわかってね。 時間の取扱い(第2部): 関数 Simon Gniadkowski 2014.02.12 19:42 #38 zortharg: データ型促進ルールがそのように作用するのかと心配になりました。OK、では。 datetime - datetime = long (秒の長さ) datetime +/- seconds(long) = datetime(別の日付) datetime +/-秒(int) = datetime(別の日付) でも、X=Y-Z とか (Y-Z)/60 とか、X はすでに long か int で宣言されていて、Y と Z は datetime である場合、これはとてもとてもまずいことでしょうか?もしそうなら、static_castはすべてを解決してくれるのでしょうか？ Raptorukさん、 タイムゾーンに依存 しないのですね。 OK、datetimeが0になるのはどのタイムゾーンですか？ しかし、取引が金曜日の東部時間午後5時に停止することは分かっていても、時間0（1970年1月1日の午前0時）がどのタイムゾーンにあるか分からない場合はどうでしょうか？そうなると問題がありますね。 いいえ......あなたは知っているかもしれませんが、私は知らないので、知らないのです。 私はブローカーのタイムゾーンを知っているので、それに応じて金曜日の午後5時を調整し、金曜日の午後5時の調整済みdatetimeを取得することができます。 ydrol 2014.02.12 22:58 #39 zortharg: データ型促進ルールがそのように機能するのか心配だったのです。OK、では。 datetime - datetime = long (秒の長さ) datetime +/- seconds(long) = datetime(別の日付) datetime +/- 秒(int) = datetime(別の日付) しかし、X=Y-Zとか、(Y-Z)/60とか、Xがすでにlongまたはintとして宣言されていて、YとZがdatetimeの場合、これはとてもとても悪いことでしょうか？もしそうなら、static_castはすべてを解決するのでしょうか？ これらは「昇進のルール」ではなく、私が分別を持っているだけです（そうであってほしい！）。 私自身、上記のようなタイプ分けをするのが一般的でしょう。 もし、私の計算結果が1970年1月1日からの秒数であれば（タイムゾーンに関係なく）、私はそれをdatetimeの ままにしておくでしょう。 それ以外のもの(継続時間、1970年1月1日からの分など)はlongとして 保存することになるでしょう。(特に典型的な持続時間などではintに することもあります) とはいえ、MQL4の設計者がどのようにしてすべてのdatetimeにUTCを義務付けず 、すべてのブローカーにUTCデータを送らせ、クライアントがそれをlocaltimeで解釈するようにしたのか、私は不可解に思っています。 なぜなら、彼らの現在のアプローチは、不必要に下流のすべてを複雑にするからです。それは、バックテスト中のGMT時間の計算やセッションのオープン/クローズ 時間を、すべてのティックデータのソースに対して正しく実行したい場合、必要以上に難しくしてしまいます。 (例えば、Alpariはヒストリカルデータに複数のタイムゾーンがあるので、バックテスト時にデータソースに注意する必要があります) PS 先ほどの誤字を編集しました :) 削除済み 2014.02.14 04:46 #40 ydrol、神聖なる愛とやらのために、static_castがmql4で使えるかどうか、もし知っているなら教えてください！C++と同じですか？C++と同じなのでしょうか？このページhttps://docs.mql4.com/basis/types/casting は、このことについて全く触れていませんし、フォーラムでも、どこにも見当たりません。私のコーディングでは、datetimeをlongにするだけでなく、datetimeをdoubleにするなど、避けられない状況に常に遭遇しているので、それを正しく行いたいのです。例えば、このプログラムはサンプルが週のどの部分にあるのかを判断し、それに応じて計算でそれを強調します。しかし、週の秒数に対する時間のモジュールはまだdatetime型の変数で、他のものにキャストできない限り、そのように固定されています。しかし、私はこの変数に対して数学的関数を実行し、最終的にdoubleにする必要があるのです。このような場合、どのようにタイプキャストすればよいのでしょうか？ raptoruk、「いいえ......たぶんあなたはそうでしょうが、私はそうではないので、いいえ、私たちはそうではありません。私にも、あなたにも、私たちにも関係なく、「タイムゾーンに依存しない」というあなたの先ほどの発言の正当性に関わることなのです。なぜなら、ブローカーがどのタイムゾーンにいるかは関係なく、FXの取引はブローカーの時計に従わないからです。金曜と日曜は東部時間午後5時です。GMTでは午後10時です。そして、サマータイム/標準時はどうなんだ!それはどうなんだ!国によっては、1時間足さないとか、1時間引くとか、違う日にするとか、いい方法がないと、1年のうちで1時間ずれたコードになってしまうかもしれない。私、ブローカーが決まらないんです。今試しているブローカーはGMT+2なのだが、デモ口座を 見る限りでは、あまり好きではないのだ。そして、私は本当のために1を試してみて、多分私は代わりに別のものを使用したいと思うでしょう。だから、ブローカーのタイムゾーンがプログラムにハードコードされないようにするのは、簡単なことだと思う。またあの人みたいに、質問を額面通りに受け止めずに、何でもかんでも侮辱を浴びせるきっかけにねじ曲げようとしないでね。 12345 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
datetimeのタイムゾーン(1970年からの秒数)は、UTCを基準にしています。UnixTimeと同じです。これは、UnixTime - 64 bit unix time です。
datetime - datetime = long (秒の長さ)
datetime +/- seconds(long) = datetime(別の日付)
datetime +/- seconds(int) = datetime(別の日付)
荒らしに餌を与えないでください。
あなたが反応すると、あなたは荒らしに力を与えてしまいます。あなたが荒らしを無視すると、荒らしは注意を引くために飢え、やがて死にます。
私は、あなたが素晴らしい貢献をしてきたと思います。あなたの投稿は簡潔で、よく教えてくれるし、あなたの努力に対してたくさんの「ありがとう」のレスをもらっている。
ええ、あなたはこの人のためにできることはすべてやったと思います。
GMT（グリニッジ標準時）の時刻を指定するにはどうすればよいですか？
mql4は壊れた時間の概念を使っていることを忘れていました。タイムゾーンはどこから来たかに依存します。したがって、ブローカー、コンピュータ、バックテストなど複数のソースがあるため、すべての問題が発生します。
データ型促進ルールがそのように作用するのかと心配になりました。OK、では。
datetime - datetime = long (秒の長さ)
datetime +/- seconds(long) = datetime(別の日付)
datetime +/-秒(int) = datetime(別の日付)
しかし、もし私が X=Y-Z とか (Y-Z)/60 とか言った場合、X はすでに long か int として宣言されていて、Y と Z は datetime ですが、これはとても、とても悪いことでしょうか？もしそうなら、static_castですべて解決するのでしょうか？
Raptorukさん、タイムゾーンに依存しないのです。もちろん、午後2時と午後3時の差は、どのタイムゾーンでも3600です。しかし、金曜日の 東部時間午後5時に取引が停止することが分かっていても、時間0（1970年1月1日の午前0時）がどのタイムゾーンにあるか分からない場合はどうでしょうか？そうすると、問題がありますね。1970年1月1日は木曜日でしたね。もし、タイム0がGMTであれば、その46時間後、つまり604800をモジュレーションした165600で取引が停止することになります。つまり、1週間が604800秒なので、604800で割った余りをX%604800の算術演算で計算し、165600で取引が停止するのです。しかし、ブローカーがそれより2タイムゾーン東にあり、彼らのジャンクが7200高いタイムスタンプを持つ場合、time%604800が165600ではなく、172800で取引が停止されるのです。
報告された時間インデックスについて不確実性があるように見えます。私は、私のコードに、取引が開始され停止される604800のモジュロの時間を計算させなければならないと思います、念のため。iTime('USDJPY',60,X)のようなものを調べて、48時間のギャップを見つけようと思っているんだ。iTimeは "open "時間、つまり1時間の始まりの時間であることは間違いないですよね？つまり、2日間のギャップの前の最後のタイムインデックスの1時間後に取引が停止し、ギャップ後の最初のタイムインデックスの始まりで正確に再開し、604800の倍数を追加すると、単に週を変更します。しかし、もしある週で最後の1時間が欠落していたり、最初の1時間が欠落していたらどうするのか、というような複雑な問題が追加されるでしょう。iTime('USDJPY',1,X)を使って、せいぜい分単位でずれるようにすればいいかもしれない。
おお、すごい、たくさんの投稿がこの一件で一気に加速しましたね。他の人にもわかるように、結局raptorukは大丈夫なんだろうけど、罵詈雑言は歓迎されないから、ydrolとかraptorukとか新しいことを言う人でないなら投稿をやめればいい、私はあなたの感情状態を一方的に気にしないから荒らしじゃないし、もし何かもっとなげかけたいことがあるなら耳に入らないことをわかってね。
データ型促進ルールがそのように作用するのかと心配になりました。OK、では。
datetime - datetime = long (秒の長さ)
datetime +/- seconds(long) = datetime(別の日付)
datetime +/-秒(int) = datetime(別の日付)
でも、X=Y-Z とか (Y-Z)/60 とか、X はすでに long か int で宣言されていて、Y と Z は datetime である場合、これはとてもとてもまずいことでしょうか?もしそうなら、static_castはすべてを解決してくれるのでしょうか？
Raptorukさん、 タイムゾーンに依存 しないのですね。
しかし、取引が金曜日の東部時間午後5時に停止することは分かっていても、時間0（1970年1月1日の午前0時）がどのタイムゾーンにあるか分からない場合はどうでしょうか？そうなると問題がありますね。
データ型促進ルールがそのように機能するのか心配だったのです。OK、では。
datetime - datetime = long (秒の長さ)
datetime +/- seconds(long) = datetime(別の日付)
datetime +/- 秒(int) = datetime(別の日付)
しかし、X=Y-Zとか、(Y-Z)/60とか、Xがすでにlongまたはintとして宣言されていて、YとZがdatetimeの場合、これはとてもとても悪いことでしょうか？もしそうなら、static_castはすべてを解決するのでしょうか？
これらは「昇進のルール」ではなく、私が分別を持っているだけです（そうであってほしい！）。 私自身、上記のようなタイプ分けをするのが一般的でしょう。
もし、私の計算結果が1970年1月1日からの秒数であれば（タイムゾーンに関係なく）、私はそれをdatetimeの ままにしておくでしょう。
それ以外のもの(継続時間、1970年1月1日からの分など)はlongとして 保存することになるでしょう。(特に典型的な持続時間などではintに することもあります)
とはいえ、MQL4の設計者がどのようにしてすべてのdatetimeにUTCを義務付けず 、すべてのブローカーにUTCデータを送らせ、クライアントがそれをlocaltimeで解釈するようにしたのか、私は不可解に思っています。
なぜなら、彼らの現在のアプローチは、不必要に下流のすべてを複雑にするからです。それは、バックテスト中のGMT時間の計算やセッションのオープン/クローズ 時間を、すべてのティックデータのソースに対して正しく実行したい場合、必要以上に難しくしてしまいます。
(例えば、Alpariはヒストリカルデータに複数のタイムゾーンがあるので、バックテスト時にデータソースに注意する必要があります)
PS 先ほどの誤字を編集しました :)
ydrol、神聖なる愛とやらのために、static_castがmql4で使えるかどうか、もし知っているなら教えてください！C++と同じですか？C++と同じなのでしょうか？このページhttps://docs.mql4.com/basis/types/casting は、このことについて全く触れていませんし、フォーラムでも、どこにも見当たりません。私のコーディングでは、datetimeをlongにするだけでなく、datetimeをdoubleにするなど、避けられない状況に常に遭遇しているので、それを正しく行いたいのです。例えば、このプログラムはサンプルが週のどの部分にあるのかを判断し、それに応じて計算でそれを強調します。しかし、週の秒数に対する時間のモジュールはまだdatetime型の変数で、他のものにキャストできない限り、そのように固定されています。しかし、私はこの変数に対して数学的関数を実行し、最終的にdoubleにする必要があるのです。このような場合、どのようにタイプキャストすればよいのでしょうか？
raptoruk、「いいえ......たぶんあなたはそうでしょうが、私はそうではないので、いいえ、私たちはそうではありません。私にも、あなたにも、私たちにも関係なく、「タイムゾーンに依存しない」というあなたの先ほどの発言の正当性に関わることなのです。なぜなら、ブローカーがどのタイムゾーンにいるかは関係なく、FXの取引はブローカーの時計に従わないからです。金曜と日曜は東部時間午後5時です。GMTでは午後10時です。そして、サマータイム/標準時はどうなんだ!それはどうなんだ!国によっては、1時間足さないとか、1時間引くとか、違う日にするとか、いい方法がないと、1年のうちで1時間ずれたコードになってしまうかもしれない。私、ブローカーが決まらないんです。今試しているブローカーはGMT+2なのだが、デモ口座を 見る限りでは、あまり好きではないのだ。そして、私は本当のために1を試してみて、多分私は代わりに別のものを使用したいと思うでしょう。だから、ブローカーのタイムゾーンがプログラムにハードコードされないようにするのは、簡単なことだと思う。またあの人みたいに、質問を額面通りに受け止めずに、何でもかんでも侮辱を浴びせるきっかけにねじ曲げようとしないでね。