2024.04
林貴晴/AMSER Inc.
MQL5では、ブローカーが様々なサーバー時間を採用しています。主な時間設定には日本時間(JST)、夏時間を含むGMT+2/+3、グリニッジ標準時間(GMT)があります。これらの時間設定の違いは、エキスパートアドバイザー(EA)の開発や運用において様々な問題を引き起こします。特に、サーバーの時間帯によって日足の本数が異なり(GMT+2/+3では週に5本、それ以外では6本)、また年月日や曜日の変更時刻が異なるため、EAが設計通りに動作しない事態が発生しやすくなります。
この記事では、Unix時間を使用して、日本時間(JST)をグリニッジ標準時間(GMT)に適応させる方法を説明します。この方法を用いることで、EAの時間を管理し、異なる時間設定のブローカーにおける日足の本数、年月日、および曜日の違いに柔軟に対応することが可能となります。
MQL5では、以下の4つの時間関数を利用して異なる種類の時間を取得できます。
最後に受け取ったサーバー時間を返します。OnTick()ハンドラでは、最新のティック時間が返され、その他の状況では「気配値表示」時間が使用されます。土日やサーバーが停止している期間は、この関数は更新されません。
クライアント端末(PCやVPS)の時間を基に計算されたサーバー時間を返します。バックテストでは、TimeCurrent()と同じ値を返します。
クライアント端末のローカル時間を返します。バックテストでは、TimeCurrent()と同じ値を返すため、テスト中の時間にずれが生じます。
クライアント端末のローカル時間から計算されたGMT時間を返します。こちらもバックテストではTimeCurrent()と同じ時間が返されるため、注意が必要です。
特にTimeLocal()とTimeGMT()は、バックテスト時に時間ずれが生じます。そのため、OnTick()ハンドラで動作するEAではTimeCurrent()を使用することが推奨ます。
この例ではフィリップ証券が採用している日本時間(JST)をグリニッジ標準時間(GMT)に変換する方法を説明します。
日本時間(JST)はグリニッジ標準時間(GMT)よりも9時間進んでいます。単に時間を9時間戻すだけでは、日付や曜日が変わる場合がありますし、月末や年末をまたぐ場合にはさらなる調整が必要になることもあります。これらの問題を解決するために、時間を直接変更するのではなく、Unix時間(1970年からの経過秒数)を用いて調整を行います。以下のコードはその一例です。
MqlDateTime GMT; TimeToStruct(TimeCurrent()-9*60*60,GMT); Comment(GMT.hour);
解説)
MqlDateTime構造体GMTを宣言します。
TimeToStruct()関数はDateTime形式の秒数をMqlDateTime構造体に変換代入します。
TimeCurrent()関数は最後に取得したサーバー時間を1970年からの経過秒数として返します。9時間×60分×60秒(9時間分の秒数)を引くことでグリニッジ標準時間(GMT)に変換しています。時間のずれがバックテスト時に生じないように、TimeCurrent()関数を基準にしています。
この方法では、時間、日付、月、年の調整が自動的に行われ、プログラマが個別に調整する手間を省くことができます。
MQL5で時間を扱うことは、プログラミングの中で最も難しい部分の一つです。年月日や曜日など、多くの要素を考慮して調整する必要がありますが、Unix時間を活用することで、日足の数などを自動的に調整することが可能です。この方法を使って、簡単かつ正確なコーディングを目指しましょう。
林 貴晴(AMSER株式会社代表取締役)
内資系薬品会社で約10年勤務の後、
外資系製薬会社(現IQVIA及びGSK)で合計約10年を勤務
その後EA AMSERを開発し、その成績を評価され、株式会社ゴゴジャンの部長として抜擢。
現在はAMSER株式会社代表取締役。