MetaTrader5
Wirtschaftskalender für Backtests: So synchronisierst du historische Daten in MetaTrader 5
Um es kurz zu machen: Der integrierte Wirtschaftskalender von MetaTrader 5 ist nicht (vollständig) mit historischen Kursen synchronisiert. Die Kursdaten sind mit Zeitstempeln versehen, die den zum Zeitpunkt der Bildung jeder entsprechenden Kerze geltenden Zeitzonen entsprechen. Sobald die Kerzen 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 viele Broker einem bestimmten Zeitplans folgen, einschließlich der Umstellung auf und von der Sommerzeit, können die Zeitstempel historischer Ereignisse um eine Stunde verschoben sein, relativ zu den zugehörigen Kerzen – und das betrifft etwa die Hälfte des Jahres. Darüber hinaus ändern Broker manchmal die Zeitzonen radikaler als nur den Wechsel zur Sommerzeit. Historische Kurse können dann einige Stunden nach links oder rechts verschoben erscheinen, im Vergleich zu den Zeitpunkten der wirtschaftlichen Ereignisse, die ursprünglich stattfanden, aber jetzt im aktualisierten Zeitplan des Servers angezeigt werden. Berücksichtigt man, dass Nachrichten aus verschiedenen Ländern mit eigenen Sommerzeitregelungen kommen und dein Server in einer Region mit einem anderen Zeitplan sein kann, können die Zeiten der Veröffentlichung von Nachrichten auf den Charts sogar auf eine merkwürdige Weise „springen“ (zum Beispiel über mehrere Wochen im Frühling und im Herbst). All dies mag online nicht so wichtig erscheinen, aber was ist, wenn wir eine nachrichtengestützte Strategie testen wollen? Ja, man könnte sagen, dass der Kalender im MetaTrader-Tester nicht nativ unterstützt wird, aber viele Trader handeln gerne mit Nachrichten, und alle anderen sollten die Nachrichten im Auge behalten, um sich rechtzeitig aus dem Markt zurückzuziehen, bevor es während der Nachrichtenveröffentlichungen turbulent wird. Daher ist das Backtesting mit dem Kalender von großer Bedeutung. Es liegt also nahe, den Kalender in einen externen Speicher (Datei, Datenbank) zu exportieren und dann in den Tester zu importieren. Ein solches Archivierungstool für das Kalender-in-Tester-Erlebnis wurde im Algotrading-Buch vorgestellt. Hier begegnen wir dem Problem der Desynchronisation historischer Kurse mit historischen Ereignissen. Um es einfach zu halten, wurde dieses Problem im Buch nicht gelöst. Jetzt ist es gelöst dank der erweiterten Version von CalendarCache.mqh und dem Indikator CalendarMonitorCachedTZ.mq5. Dies ist nur eine leicht geänderte Version von CalendarMonitorCached.mq5 aus dem Buch. Der Indikator überwacht Ereignisse aus den Nachrichten und aktualisiert dynamisch eine Tabelle auf dem Chart mit mehreren vergangenen und bevorstehenden Ereignissen. Die gesamte Arbeit, die mit der Zeitkorrektur verbunden ist, erfolgt im Hintergrund – in der anderen öffentlichen Bibliothek TimeServerDST.mqh. Um besser zu verstehen, wie die Zeitkorrektur funktioniert, kann man das Skript CalendarCSVForDates.mq5 verwenden und die CSV-Dateien mit und ohne Korrektur nebeneinander vergleichen. Und so ist die Bibliothek in den Quellcode beider Programme eingebettet – im Skript und in diesem Indikator. #include <TimeServerDST.mqh> // Einfügen vor dem Kalendercache ermöglicht die Unterstützung der Zeitzonenkorrektur
#include <MQL5Book/CalendarFilterCached.mqh>
#include <MQL5Book/CalendarCache.mqh>
Wie im ursprünglichen Indikator gibt es den Eingabestring CalendarCacheFile, wo du den Namen der Kalenderdatei zum Schreiben oder Lesen angeben kannst. Wenn der Indikator an ein Online-Chart mit leerem CalendarCacheFile angehängt wird, arbeitet er in Echtzeit mit dem integrierten Kalender. Wenn der Indikator mit einem spezifischen Namen im CalendarCacheFile ausgeführt wird und die Datei nicht existiert, exportiert der Indikator die Kalenderdatensätze in die Cache-Datei (erstellt die Datei) und beendet den Vorgang. In dieser Phase sollten/könnten die Zeitstempel korrigiert werden (siehe FixCachedTimesBySymbolHistory unten). Wenn der Indikator mit einem Namen einer vorhandenen Cache-Datei im CalendarCacheFile ausgeführt wird, lädt er den Cache und arbeitet mit dieser Kopie genau wie mit dem integrierten Kalender. Dies ist besonders nützlich für den Tester. Bitte vergesst nicht, dass der Tester zusätzliche Dateien benötigt, in unserem Fall die vorbereitete Online-Kalenderdatei, in der Direktive #property tester_file ODER du solltest die Kalenderdatei in den gemeinsamen Ordner C:/Users/<User>/AppData/Roaming/MetaQuotes/Terminal/Common/ legen. Natürlich kann der Cache auch in einen EA während Backtests und Optimierungen geladen werden. Der Eingabestring FixCachedTimesBySymbolHistory wird folgendermaßen verarbeitet: Wenn er leer ist, speichert der Indikator den Cache ohne Zeitkorrekturen. Um Zeitkorrekturen während des Exports zu aktivieren, musst du ein Symbol angeben, das zur empirischen Erkennung der historischen Zeitzonen des Servers verwendet wird. Es funktioniert basierend auf der Historie der H1-Kurse, vorzugsweise "XAUUSD" oder "EURUSD". Mit diesem Eingabeparameter werden nur ein paar Zeilen in die neue Version des Indikators hinzugefügt: if(StringLen(FixCachedTimesBySymbolHistory))
cache[].adjustTZonHistory(FixCachedTimesBySymbolHistory, true);
Die Methode adjustTZonHistory wurde speziell in die CalendarCache-Klasse für die Anpassung der Zeitstempel eingeführt und ihre Implementierung nutzt die Interna von TimeServerDST.mqh. Die Methode sollte nur online aufgerufen werden (nicht im Tester). Normalerweise sollte die Methode auf Cache-Objekten aufgerufen werden, die aus dem integrierten Kalender gefüllt wurden, direkt nach dem Füllen. Andernfalls, wenn der Cache aus einer Kalenderdatei geladen wird oder wenn die Methode bereits vorher aufgerufen wurde, könnten die Inhalte des Caches bereits angepasst sein. Dann würdest du eine Korrektur auf die Korrektur anwenden und falsche Zeitstempel erhalten. Der zweite Parameter (true) weist die Methode an, die Grenzen der angewendeten Änderungen im Protokoll zu protokollieren. So etwas wie: Zeitkorrektur begann am 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 eine Zeit und die ID eines Ereignisses, bei dem eine neue Abweichung festgestellt wurde, den Zeitversatz des Servers zum Zeitpunkt des Ereignisses und die Differenz, die auf alle nachfolgenden Zeitstempel angewendet werden muss, um die Verzerrung in der Serverzeit zum Zeitpunkt des Kalender-Cachings zu beseitigen. Die angehängten mqh-Dateien (CalendarFilter.mqh, CalendarCache.mqh, QuickSortStructT(Ref).mqh) enthalten Bugfixes und Verbesserungen im Vergleich zu ihren ursprünglichen Versionen aus dem Buch. Updates 11.11.2024 - kleine Bugfixes und Updates in CalendarFilter.mqh, CalendarCache.mqh; 22.11.2024 - kleine Bugfixes und Verbesserungen in CalendarCache.mqh.
2024.11.11
