Handelszeiten im Trading-Bot: Wie Zeitzonen und Sommerzeit Strategien still verschieben

Fast jede automatisierte Strategie enthält eine Zeitangabe: ab wann gehandelt wird, bis wann, wann spätestens glattgestellt wird. Diese Angabe steht oft als schlichte Konstante im Code - und ist damit mehrmals im Jahr falsch. Der Fehler meldet sich nicht, nichts stürzt ab. Der Bot handelt einfach eine Stunde daneben.

Drei Uhren, die nicht dasselbe anzeigen

Im Spiel sind mindestens drei Zeitangaben: die Uhr des Rechners oder Servers, auf dem der Bot läuft, die Zeitstempel aus dem Datenfeed und die Zeit der Börse, an der das Instrument gehandelt wird. Handelszeiten sind in der Zeit der Börse definiert, nicht in der eigenen. Wer Regeln in lokaler Zeit formuliert, koppelt die Strategie an eine Uhr, die mit dem gehandelten Markt nichts zu tun hat - besonders deutlich, sobald der Bot auf einem Server in einer anderen Region läuft.

Warum eine feste Stundendifferenz nicht reicht

Europa und die USA stellen die Uhr nicht am selben Tag um. Die EU wechselt am letzten Sonntag im März und am letzten Sonntag im Oktober, die USA am zweiten Sonntag im März und am ersten Sonntag im November. Dazwischen entstehen jedes Jahr zwei Fenster - im Frühjahr rund zwei bis drei Wochen, im Herbst etwa eine Woche -, in denen die Differenz zwischen deutscher Zeit und US-Börsenzeit eine andere ist als im Rest des Jahres. Eine fest eingetragene Verschiebung ist in diesen Fenstern garantiert falsch.

Der Backtest ist genauso betroffen

Historische Daten tragen Zeitstempel, die mit der damals gültigen Verschiebung gelesen werden müssen, nicht mit der heutigen. Wird das übersehen, hängt ein Session-Anker - etwa der Beginn einer Opening Range - für ganze Abschnitte der Historie an der falschen Kerze. Das Ergebnis sieht trotzdem sauber aus, es beantwortet nur eine andere Frage als die gestellte. Besonders tückisch ist das, weil der Fehler nur Teile des Testzeitraums betrifft und damit aussieht wie verändertes Marktverhalten.

Was ein Zeitfenster allein nicht abdeckt

• Börsenfeiertage, an denen gar nicht gehandelt wird - ein reines Zeitfenster kennt keine Feiertage
• Verkürzte Handelstage rund um Feiertage, an denen ein übliches Glattstellen zu spät käme
• Instrumente mit abweichenden Sessions - ein Fenster, das für ein Instrument passt, muss für das nächste nicht passen
• Rollover-Termine bei Futures, an denen sich die Liquidität auf den nächsten Kontrakt verlagert

Wie es stattdessen aufgebaut sein sollte

• Eine einzige Referenzzeit festlegen und durchgängig verwenden, statt an mehreren Stellen hin und her zu rechnen
• Regeln in der Zeit der Börse formulieren und die Umrechnung ausschließlich an den Rändern vornehmen
• Die Umrechnung über eine gepflegte Zeitzonendatenbank lösen statt über eine Stundenkonstante - die Umstellungsregeln ändern sich gelegentlich
• Handelszeiten, Puffer vor Handelsschluss und Feiertagsverhalten konfigurierbar halten statt im Code zu vergraben
• In jedem Trade-Protokoll die Zeit sowohl in der Referenzzeit als auch in Börsenzeit mitschreiben, damit ein Versatz überhaupt auffällt

Wie sich planbare Termine zusätzlich zur reinen Uhrzeit berücksichtigen lassen, steht im Beitrag zum News-Filter im Trading-Bot.

Warum der Standort des Servers dabei eine Rolle spielt, behandelt der Beitrag zum VPS für den ATAS-Trading-Bot.

Zeitzonen sind kein spannendes Thema, aber sie gehören zu den wenigen Fehlerquellen, die sich vollständig vermeiden lassen. Vorausgesetzt, die Entscheidung fällt beim Entwurf - und nicht nach der ersten Woche, in der die Strategie eine Stunde daneben gehandelt hat.