私は完全に迷子になった - ページ 5

新しいコメント
 
静的キャストの意味がわからない。タイムゾーンの問題は、mqlでは厄介です。古いmql4では、ユーザーがブローカーのオフセットに設定するグローバル変数を持っているアプローチでしたが、新しいtimegmt関数を使って gmt時間を取得することもできますが、これはバグがあるという報告をいくつか見かけました。また、バックテスト中にどのような挙動をするかはわかりません。残念ながら、全体的に混乱した状態です。しかし、コードで回避することは不可能ではありません。
 
RaptorUK: さて、datetimeが0になるのはどのタイムゾーンでしょうか？
それはあなたのブローカーのサーバーのタイムゾーンです。期間。mt4から取得するすべての日付は、あなたのサーバーのタイムゾーンです。(TimeLocal() と新しいmt5のTimeGMTを 除く)
ydrol です。MQL4の設計者が、なぜすべてのdatetimeにUTCを義務付けない ことにしたのかが不思議でなりません。

10年以上前のことに戸惑う？Y2Kをご存知ですか？そうでなければ、なぜ日付が1年につき2桁で保存され、1999年以降が1900年や19100年になっているのかに戸惑うだけでしょう。

70億人の世界でIPアドレスが42億個に制限されていることに戸惑いを感じているのではないでしょうか。DARPAでは、国内の既存（数十台）のメインフレームコンピュータを接続しようとしたときに、誰かがそのような決定を下しました。今、私たちはIPv4からIPv6に変換しているところです。

自分自身を乗り越える。ベルジャ・キングじゃないんだから、自分の 思い通りにならない。誰かが、当時は合理的と思われた決定を下し、今はそうではない。それに対処してください。

 
zortharg:

ydrolさん、神聖なる愛というか何というか、static_castがmql4で使えるかどうか、ご存じでしたら教えてください！（笑）。C++と同じなのでしょうか？このページhttps://docs.mql4.com/basis/types/casting は、このことについて全く触れていませんし、フォーラムでも、どこにも見当たりません。私のコーディングでは、datetimeをlongにするだけでなく、datetimeをdoubleにするなど、避けられない状況に常に遭遇しているので、それを正しく行いたいのです。例えば、このプログラムはサンプルが週のどの部分にあるのかを判断し、それに応じて計算でそれを強調します。しかし、週の秒数に対する時間のモジュールはまだdatetime型の変数で、他のものにキャストできない限り、そのように固定されています。しかし、私はこの変数に対して数学的関数を実行し、最終的にdoubleにする必要があるのです。でも、このような場合、どのようにタイプキャストすればいいのでしょうか？

ドキュメントにデータ型とタイプキャストについてのセクションがあります エディタを使用しているときにF1を押していますか？

 
WHRoeder:
それはあなたのブローカーのサーバーのタイムゾーンです。期間。mt4から取得するすべての日付は、あなたのサーバーのタイムゾーンです。(TimeLocal() と新しいmt5のTimeGMTを 除く)

10年以上前のことに戸惑う？Y2Kをご存知ですか？もし知らないなら、なぜ日付が1年につき2桁で保存され、1999年以降が1900年や19100年になるのかに困惑していることでしょう。

70億人の世界でIPアドレスが42億個に制限されているのも不思議でしょうがない。DARPAの誰かが、国内の既存（数十台）のメインフレームコンピュータを接続しようとしたときに、この決定を下したのです。今、私たちはIPv4からIPv6に変換しているところです。

自分自身を乗り越える。ベルジャ・キングじゃないんだから、自分の 思い通りにならない。誰かが、当時は合理的と思われた決定を下し、今はそうではない。それに対処してください。

いや、もういいや。真面目な話、設計時になぜそのような決定がなされたのか、私は困惑しています。そして、それを言うことは私の権利として完全に認められている。言論の自由とかね。私以上に私を弾圧しようとする権利はない。それは、すでにutcを使用していた理由で確立された時間形式に基づいており、10年よりもはるかに古いものです。そして今、mql4は、率直に言って私を困惑させる決定のためにタイムゾーンの問題を抱えています。そして、私はそう言うことが許されているのです。あなたはy2kについて好きなだけ剽窃することができます、それは何の違いもありません。私は20年近くシステム統合の仕事をしていますが、UTCに固定しないのは設計上の悪い判断のように見えます。他の人が意見を言うのを処理できないなら、ごめんなさい。
 
WHRoeder:
ブローカーのサーバーのタイムゾーンです。PERIODです。mt4 から取得するすべての日付は、あなたのサーバーのタイムゾーンになります。(TimeLocal() と新しいmt5のTimeGMTを 除く)。
とGlobalVariableSet()はPCの時計(未モデリング)から得たGMT時間です。
 

現在、私のTimeZone/Session関数を整頓されたmql4++クラスに移行しているため、再びこの件を掘り起こすことにしました

WHRoeder: Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.

しかし、そもそもなぜそうしなければならないのか、まだ謎のままです。タイムゾーン情報の管理に関するベストプラクティスは、1988年以来、長い間存在しています。 ISO 8601の場合

ISO 8601のタイム ゾーンは、現地時間（場所を特定しない）、UTC、UTCからのオフセットで表現されます。

時刻表示でUTC関係の情報が提供されない場合、その時刻は現地時間であると見なされます。同じタイムゾーンで通信する場合はローカルタイムと仮定しても安全かもしれませんが、異なるタイムゾーンを越えて通信する場合に使用すると曖昧に なります。[My Emphasis] 通常、標準の表記法を使用してタイムゾーン（ゾーン指定子）を示すことが望ましいとされています".

下線の部分は、IT業界では30年近く前から知られていたものです。MQLの日付形式はUnixTimeから派生したものです（1970年1月1日というマジックデイトを空中から取り出したわけではありません）ので、そのことはもうわかっているはずです。

1988年にPOSIXはUnixTimeを批准しています。

"POSIX委員会は、ライブラリ関数の複雑化に対する議論に揺さぶられた。 と、UTC時刻の要素 で シンプルに Unix時刻をしっかり定義した。[My Emphasis]

10年前（といってもそれほど昔でもないのですが）、クライアント・サーバーシステムを設計していたシステム設計者や開発者は、時間に関わる重要な情報をやり取りしていたので、現在のタイムゾーンの混乱を予測・回避するのに十分な情報を持っていたはずです。あるタイムゾーンにいるトレーダーは、別のタイムゾーンでデータを取得し、それを別のタイムゾーン（例えばNY）で解釈して欲しいことがあります。唯一の言い訳は

- 無知

- 優先順位が低い (TZの混乱は、トレーダーではなくブローカーに利益をもたらす？)

- このような、外からはわからない技術的な配慮/制約/要件がある。チャートとか描いたら？既知の オフセットを加算/減算するのはそれほど難しくはないのですが？

以上、前述したようなことが気になります。バックテスト中にGMT時間を計算するコードを書く必要はないように思います。しかし、TimeGMT()とTimeLocal()は正しくモデル化されていません。（両方とも過去のデータから得られた非特定のTZに設定されています）したがって、バックテスト中にUTCとセッション開始・終了時間を正確に計算するために、独自のタイムゾーン関数を作成する必要があるのです。

PS WHRoederから "get over myself "と言われた皮肉は、失われない:)

12345
新しいコメント