Economic Calendar Monitor and Cache for Backtesting on History - Indikator für den MetaTrader 5

Die Kurse sind mit Zeitstempeln versehen, die sich nach den Zeitzonen richten, die auf dem Server zum Zeitpunkt der Bildung des jeweiligen Balkens in Kraft waren.

Sobald die Balken gebildet sind, bleiben sie unverändert, einschließlich ihrer Zeitstempel. Der Wirtschaftskalender hingegen liefert Informationen über Ereignisse (Vergangenheit, Gegenwart und Zukunft), die an die aktuelle Zeitzone des Servers gebunden sind. Da sich viele Broker an einen bestimmten Zeitzonenplan halten, der auch das Ein- und Ausschalten der Sommerzeit einschließt, können die Zeitstempel der historischen Ereignisse für etwa die Hälfte eines jeden Jahres um eine Stunde gegenüber den zugehörigen Balken verschoben sein.

Darüber hinaus ändern Broker die Zeitzonen manchmal radikaler als nur durch die Umstellung der Sommerzeit. Historische Kurse können dann im Vergleich zum Zeitpunkt der ursprünglichen wirtschaftlichen Ereignisse um mehrere Stunden nach links oder rechts verschoben sein, werden aber nun vom Kalender in der aktualisierten Zeitzone des Servers gemeldet.

Da die Nachrichten aus verschiedenen Ländern mit eigener Sommerzeit stammen und Ihr Server sich in einer Region mit anderer Zeitzone befinden kann, können die Zeiten der Nachrichtenveröffentlichungen auf den Diagrammen sogar auf merkwürdige Weise hin- und herspringen (z. B. mehrere Wochen lang im Frühjahr und im Herbst).

All dies scheint online nicht so wichtig zu sein, aber was ist, wenn wir eine auf Nachrichten basierende Strategie testen wollen?

Ja, man kann sagen, dass der Kalender im MetaTrader-Tester nicht nativ unterstützt wird, aber viele Händler handeln gerne mit Nachrichten und alle anderen, die das nicht tun, sollten die Nachrichten verfolgen, um einfach vom Markt wegzukommen, bevor er während der Nachrichten wild wird. Backtesting mit dem Kalender ist also wichtig. Deshalb ist es sehr logisch, den Kalender in einen externen Speicher (Datei, Datenbank) zu exportieren und ihn dann in den Tester zu importieren. Eines dieser Archivierungstools für Kalender-im-Tester-Erfahrungen wurde im Algotrading-Buch vorgestellt.

Und hier stoßen wir auf das Problem der Desynchronisation von historischen Zitaten mit historischen Ereignissen. Der Einfachheit halber wurde dieses Problem in dem Buch ungelöst gelassen.

Nun ist es dank der erweiterten Version von CalendarCache.mqh und dem vorzeigbaren Indikator CalendarMonitorCachedTZ.mq5 gelöst. Dies ist nur eine leicht veränderte Version von CalendarMonitorCached.mq5 aus dem Buch.

Der Indikator überwacht Nachrichtenereignisse und aktualisiert dynamisch eine Tabelle auf dem Chart mit verschiedenen vergangenen und bevorstehenden Ereignissen.

Die gesamte Zeitkorrektur wird hinter den Kulissen durchgeführt - in der anderen öffentlichen Bibliothek TimeServerDST.mqh. Zum besseren Verständnis, wie die Zeitkorrektur funktioniert, kann man das SkriptCalendarCSVForDates.mq5 verwenden und CSV-Dateien mit und ohne Korrektur nebeneinander vergleichen.

Und hier sehen Sie, wie die Lib in die Quelltexte beider Programme - des Skripts und dieses Indikators - eingebettet ist.

#include <TimeServerDST.mqh> // Einbindung vor dem Kalender-Cache ermöglicht Unterstützung für die Korrektur von Zeitzonen
#include <MQL5Book/CalendarFilterCached.mqh>
#include <MQL5Book/CalendarCache.mqh>

Wie im Original-Indikator gibt es den String-Eingang CalendarCacheFile, in dem Sie den Namen einer CSV-Datei zum Schreiben oder Lesen angeben können.

Wenn der Indikator an einen Online-Chart mit leerer CalendarCacheFile angehängt wird, arbeitet er mit dem eingebauten Kalender on-the-fly.

Wenn der Indikator mit einem bestimmten Namen in CalendarCacheFile ausgeführt wird und die Datei nicht existiert, exportiert der Indikator die Kalendereinträge in die Cache-Datei (erstellt die Datei) und beendet sich. Dies ist die Phase, in der die Zeitstempel korrigiert werden sollten/können (siehe FixCachedTimesBySymbolHistory unten).

Wenn der Indikator mit dem Namen einer bestehenden Cache-Datei in CalendarCacheFile ausgeführt wird, lädt er den Cache und arbeitet mit dieser Kopie auf die gleiche Weise wie mit dem eingebauten Kalender. Dies ist insbesondere für den Tester nützlich.

Bitte vergessen Sie nicht, dass der Tester zusätzliche Dateien angeben muss, in unserem Fall - die vorbereitete Online-Kalenderdatei, in der Direktive #property tester_file ODER Sie sollten die Kalenderdatei in den gemeinsamen Ordner C:/Users/<User>/AppData/Roaming/MetaQuotes/Terminal/Common/ legen.

Natürlich kann der Cache auch bei Backtests und Optimierungen in einen EA geladen werden.

Der Eingabe-String FixCachedTimesBySymbolHistory wird wie folgt verarbeitet.

Wenn er leer ist, speichert der Indikator den Cache ohne Zeitkorrekturen.

Um Zeitkorrekturen während des Exports zu aktivieren, sollten Sie ein Symbol angeben, das für die empirische Erkennung von historischen Zeitzonen des Servers verwendet wird. Es funktioniert auf Basis der Historie der H1-Kurse, vorzugsweise "XAUUSD" oder "EURUSD".

Mit Hilfe dieser Eingabe werden in der neuen Version des Indikators nur ein paar Zeilen hinzugefügt:

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

Die Methode adjustTZonHistory wurde speziell in die CalendarCache-Klasse für Zeitstempelanpassungen eingeführt und ihre Implementierung verwendet Interna von TimeServerDST.mqh.

Die Methode sollte nur online aufgerufen werden (nicht im Tester).

Normalerweise sollte die Methode bei Cache-Objekten, die aus dem eingebauten Kalender gefüllt werden, direkt nach dem Füllen aufgerufen werden. Andernfalls, wenn der Cache aus einer Cal-Datei geladen wird, oder wenn die Methode bereits vorher aufgerufen wurde, könnte der Cache-Inhalt bereits angepasst sein. Dann werden Sie Fix auf Fix anwenden und falsche Zeitstempel erhalten.

Der zweite Parameter(true) weist die Methode an, die Grenzen der angewandten Änderungen in das Log zu schreiben. Etwa so:

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

Jede Zeile enthält die Zeit und die ID eines Ereignisses, bei dem eine neue Diskrepanz festgestellt wurde, den Serverzeit-Offset zum Zeitpunkt des Ereignisses und die Differenz, die auf alle nachfolgenden Zeitstempel angewandt werden muss, um die Verzerrung der Serverzeit zum Zeitpunkt des Kalender-Cachings zu beseitigen.

Aktualisierungen

11.11.2024 - kleine Fehlerbehebung und Aktualisierungen in CalendarFilter.mqh, CalendarCache.mqh;

22.11.2024 - kleine Fehlerkorrekturen und Verbesserungen in CalendarCache.mqh.