Zeit wirkt wie eine Selbstverständlichkeit. Tatsächlich ist sie im Bot-Betrieb eine Infrastrukturkomponente wie Netzwerk oder Speicher — und eine, die still ausfällt. Eine driftende Uhr erzeugt keine Fehlermeldung. Sie erzeugt Ergebnisse, die plausibel aussehen und falsch sind.
Wie Uhren auseinanderlaufen
Jeder Rechner besitzt einen Quarzoszillator, dessen Frequenz temperatur- und alterungsabhängig leicht schwankt. Ohne Korrektur läuft eine typische Serveruhr um mehrere Sekunden pro Tag vor oder nach. In virtualisierten Umgebungen kommt hinzu, dass eine ausgesetzte oder migrierte Instanz nach dem Fortsetzen mit einer eingefrorenen Uhr weiterarbeitet — der Sprung kann dann Minuten betragen.
Korrigiert wird das über Zeitsynchronisation gegen externe Referenzserver. Wichtig ist dabei der Modus: Ein harter Zeitsprung rückwärts kann in laufender Software zu negativen Zeitdifferenzen und damit zu Endlosschleifen oder Fehlberechnungen führen. Die schonende Variante gleicht die Abweichung an, indem sie die Uhr vorübergehend minimal schneller oder langsamer laufen lässt.
Ein Bot, der die Systemzeit nicht überwacht, hat eine unsichtbare Fehlerquelle im Fundament. Sie meldet sich nicht — sie verzerrt.
Was schiefgeht, wenn die Zeit nicht stimmt
- Abgelehnte Anfragen: Handelsplätze erwarten bei signierten Anfragen einen Zeitstempel innerhalb eines engen Toleranzfensters. Liegt die lokale Uhr daneben, werden Anfragen serverseitig verworfen — oft mit einer Fehlermeldung, die nach Netzwerkproblem klingt.
- Falsche Kerzenzuordnung: Wird ein Kurs dem falschen Zeitintervall zugeordnet, entstehen Signale aus Daten, die zu diesem Zeitpunkt noch gar nicht vorlagen.
- Unbrauchbare Logs: Wenn Bot, Datenbank und Handelsplatz unterschiedliche Zeiten schreiben, lässt sich im Nachhinein keine Reihenfolge mehr rekonstruieren. Genau darauf ist aber jede Fehleranalyse angewiesen.
- Verzerrte Latenzmessung: Ausführungsdauern, die aus zwei Uhren berechnet werden, sind nur so genau wie deren Differenz.
Drei Zeiten, die man nicht verwechseln darf
- Lokale Systemzeit: Die Uhr des eigenen Servers. Nur so verlässlich wie ihre Synchronisation.
- Zeit des Handelsplatzes: Maßgeblich für Order-Gültigkeit und Kerzengrenzen. Sollte regelmäßig abgefragt und der Versatz protokolliert werden.
- Monotone Uhr: Ein Zähler, der ausschließlich vorwärts läuft und von Zeitkorrekturen unberührt bleibt. Für Zeitmessungen innerhalb des Programms — Timeouts, Dauer, Abstände — ist ausschließlich diese richtig.
Der häufigste Programmierfehler in diesem Bereich ist, Dauern aus zwei Wanduhr-Zeitpunkten zu berechnen. Springt die Uhr dazwischen, entstehen negative oder absurd große Zeitspannen — und abhängige Logik reagiert unvorhersehbar.
Zeitzonen und Sommerzeit
Intern gehört alles in koordinierte Weltzeit. Umgerechnet wird ausschließlich an der Oberfläche, wenn ein Mensch die Zahl liest. Wer lokale Zeit speichert, bekommt zweimal im Jahr ein Problem: eine Stunde existiert doppelt, eine gar nicht. Für Tagesgrenzen, Handelssitzungen und Sitzungsfenster ist das direkt relevant, weil sich Auswertungszeiträume dadurch überlappen oder Lücken bekommen.
Was in die Überwachung gehört
Praktisch genügen drei Dinge. Erstens ein aktiver Zeitsynchronisationsdienst mit mehreren Referenzquellen, dessen Zustand überwacht wird — nicht nur, ob er läuft, sondern ob er tatsächlich synchron ist. Zweitens eine regelmäßige Messung des Versatzes zur Zeit des Handelsplatzes, protokolliert als Kennzahl mit Alarmschwelle. Drittens eine Startprüfung: Überschreitet der Versatz beim Hochfahren eine definierte Grenze, sollte der Bot nicht in den Handel gehen, sondern melden und warten.
Dieser dritte Punkt ist der wirksamste. Ein Bot, der bei falscher Uhr gar nicht erst startet, verursacht eine Meldung. Ein Bot, der startet, verursacht Positionen auf Basis von Daten, deren Zeitbezug nicht stimmt — und die Ursache findet man erst Tage später in der Auswertung, wenn überhaupt.
Auswirkung auf Backtests
Im Live-Betrieb erzeugt Zeitdrift Fehler, die auffallen. Im Backtest erzeugt sie Ergebnisse, die zu gut aussehen. Wird ein Kurs versehentlich einem früheren Intervall zugeordnet, verfügt die Strategie über Information, die zu diesem Zeitpunkt real nicht vorlag. Das Ergebnis ist eine Form von Vorgriff auf die Zukunft — mit dem Unterschied, dass sie nicht aus einem Denkfehler stammt, sondern aus der Infrastruktur.
Prüfen lässt sich das mit einer einfachen Kontrolle: Für jeden Datenpunkt muss der Zeitstempel des Signals nach dem Schlusszeitpunkt der Kerze liegen, aus der es abgeleitet wurde. Verletzungen dieser Regel sind ein zuverlässiger Hinweis auf ein Zeitproblem in der Datenkette.
Mehrere Instanzen, eine Wahrheit
Laufen Datenerfassung, Signallogik und Ausführung auf getrennten Rechnern, addieren sich deren Abweichungen. Zwei Server, die jeweils eine Sekunde in unterschiedliche Richtungen abweichen, liegen zwei Sekunden auseinander — genug, um Reihenfolgen im Log zu vertauschen und Zustandsabgleiche scheitern zu lassen. Alle beteiligten Systeme sollten deshalb gegen dieselben Referenzquellen synchronisieren, und der gemessene Versatz gehört als eigene Kennzahl in die Überwachung, nicht in eine Logzeile, die niemand liest.