Economic Calendar Monitor and Cache for Backtesting on History - MetaTrader 5のためのインディケータ

相場は、各対応するバーが形成された瞬間にサーバー上で有効であったタイムゾーンに従ってタイムスタンプでマークされます。

一度バーが形成されると、タイムスタンプも含めて変更されません。一方、経済カレンダーは、サーバーの現在のタイムゾーンに関連するイベント（過去、現在、未来）に関する情報を提供します。多くのブローカーは、夏時間のオン・オフを含む特定のタイムゾーン・スケジュールを順守しているため、過去のイベントのタイムスタンプは、毎年約半分の期間、関連するバーに対して1時間ずれることがあります。

また、ブローカーは夏時間を変更するだけでなく、タイムゾーンを根本的に変更することがあります。その場合、ヒストリカル・クォートは、もともと経済イベントが発生した時間に対して左右に数時間ずれているように見えるかもしれませんが、現在はサーバーの更新されたタイムゾーンでカレンダーによって報告されています。

ニュースがそれぞれのサマータイムを適用した異なる国から発信され、サーバーが他のスケジュールを適用した地域に設置されている可能性があることを考慮すると、ニュースリリースの時刻がチャート上で視覚的に前後に「ジャンプ」する可能性があります（例えば、春の数週間と秋の数週間）。

このようなことはネット上ではそれほど重要ではないように思えるが、ニュースベースの戦略をテストしたい場合はどうだろうか？

確かに、カレンダーはMetaTraderのテスターでネイティブにサポートされていないと言えますが、多くのトレーダーはニューストレードを好みますし、そうでないトレーダーは、ニュース中にマーケットが荒れる前に、単にマーケットから身を引くためにニュースに従うべきです。ですから、カレンダーを使ったバックテストは重要です。だからこそ、カレンダーを外部ストレージ（ファイルやデータベース）にエクスポートし、それをテスターにインポートすることは非常に論理的なのです。このようなカレンダー・イン・テスター体験のためのアーカイブ・ツールの一つは、アルゴトレーディングの本で 紹介されている。

そしてここで、過去の引用と過去の出来事の非同期化という問題にぶつかる。簡略化のため、この問題は本では未解決のままだった。

この問題は、CalendarCache.mqh の拡張版とインジケータCalendarMonitorCachedTZ.mq5 の おかげで解決しました。これは、書籍に掲載されているCalendarMonitorCached.mq5を 少し変更したものです。

このインジケータはニュース・イベントを監視し、チャート上のテーブルを過去と近日中のイベントで動的に更新します。

時刻修正に 関連するすべての作業は、舞台裏で別の公開ライブラリTimeServerDST.mqhで 行われます。時刻修正がどのように機能するかをよりよく理解するには、スクリプトCalendarCSVForDates.mq5を 使用して 、 修正あり/なしのCSVファイルを並べて比較 することができます。

また、スクリプトとこのインジケータの両方のプログラムのソースコードに lib がどのように埋め込まれているかを示します。

#include <TimeServerDST.mqh> // カレンダー・キャッシュの前に含めることで、タイムゾーンのフィックスアップが可能になる。
#include <MQL5Book/CalendarFilterCached.mqh>
#include <MQL5Book/CalendarCache.mqh>

オリジナルのインジケーターと同様に、文字列入力CalendarCacheFileが あり、書き込みまたは読み出し用のcal-fileの名前を指定することができます。

CalendarCacheFile が 空の状態でインジケータをオンライン・チャートにアタッチすると、 内蔵カレンダーでその場で動作します。

CalendarCacheFileに 特定の名前を指定してインジケータを実行し、ファイルが存在しない場合、インジケータはカレンダーの記録をキャッシュファイルにエクスポートし(ファイルを作成し)、終了します。これは、タイムスタンプを修正すべき/修正できる段階です(後述のFixCachedTimesBySymbolHistory を 参照)。

CalendarCacheFileに 既存のキャッシュファイルの名前を指定してインジケータを実行すると、キャッシュをロードし、内蔵カレンダーと同じようにこのコピーで動作します。これは特にテスターにとって便利です。

テスターは、#property tester_file ディレクティブで、追加ファイル（この場合、準備されたオンラインカレンダーファイル）を指定する必要があること、または、共通フォルダC:/Users/<User>/AppData/Roaming/MetaQuotes/Terminal/Common/にカレンダーファイルを配置する必要があることを忘れないでください。

もちろん、キャッシュはバックテストや最適化の際にEAにロードすることもできます。

入力文字列FixCachedTimesBySymbolHistory は以下のように処理されます。

この文字列が空の場合、インディケータは時間補正なしでキャッシュを保存します。

エクスポート時に時間補正を有効にするには、シンボルを指定する必要があります。このシンボルは、サーバーの過去のタイムゾーンを経験的に検出するために使用されます。これはH1クォートの履歴に基づいて動作し、好ましくは "XAUUSD "または "EURUSD "です。

この入力の助けを借りて、新バージョンのインジケーターには数行が追加されただけです：

         if(StringLen(FixCachedTimesBySymbolHistory))
            cache[].adjustTZonHistory(FixCachedTimesBySymbolHistory, true);

メソッドadjustTZonHistoryは、特にタイムスタンプ調整のためにCalendarCache クラスに導入され、その実装はTimeServerDST.mqhの 内部を使用します。

このメソッドはオンラインでのみ呼び出されます（テスターでは呼び出されません）。

通常、このメソッドは内蔵カレンダーから読み込まれたキャッシュ・オブジェクトに対して、読み込まれた直後に呼び出されます。そうでなければ、キャッシュが cal ファイルから読み込まれた場合、または、このメソッドが以前に呼び出された場合、キャッシュの内容がすでに調整されている可能性があります。その場合、修正に修正を重ね、間違ったタイムスタンプを取得することになる。

2番目のパラメータ（true）は、適用された変更の境界をログに書き出すようメソッドに指示します。こんな感じです：

Time fix-up started at 2021.07.19 00:30:00
2021.07.19 00:30:00: 148786 -10800 diff=-3600
2021.11.08 01:50:00: 135918 -7200 OK
2022.03.14 04:30:00: 161085 -10800 diff=-3600
2022.11.07 04:00:00: 165962 -7200 OK
2023.03.13 01:50:00: 168500 -10800 diff=-3600
2023.11.06 01:50:00: 169270 -7200 OK
2024.03.11 01:50:00: 181258 -10800 diff=-3600
2024.11.04 02:30:00: 208469 -7200 OK

各行には、新しい不一致が検出されたイベントの時刻とID、そのイベントでのサーバー時刻のオフセット、そして、カレンダーキャッシュの瞬間のサーバー時刻の偏りをなくすために、それ以降のすべてのタイムスタンプに適用されなければならない差分が含まれます。

更新内容

11.11.2024 - CalendarFilter.mqh、CalendarCache.mqhの小さなバグ修正と更新；

22.11.2024 - CalendarCache.mqhの小さなバグ修正と改良。