← Alle Artikel

Die Broker-Uhr ist nicht UTC

12 Min. Lesezeit · Veröffentlicht am 28.10.2026

Die Uhrzeit neben einer Kerze im Chart ist die Uhrzeit des Broker-Servers, weder die Weltzeit noch die mitteleuropäische Zeit. Innerhalb von drei Monaten haben wir diese Uhren mindestens neunmal verwechselt: in Backtests, in live laufenden Automaten und sogar in unserer eigenen Regel, die uns genau davor schützen sollte. Im Test des Ausbruchs aus der New Yorker Session verschob der Fehler alle Sessions um 2–3 Stunden und verriet sich durch eine merkwürdige Zahl: Die Strategie ergab 3 Trades, das Placebo 127. Die billigste Kontrolle war die Frage, zu welcher Uhrzeit sich Gold am stärksten bewegt.

Abkürzungen: UTC ist die Weltzeit, von der aus alle Zeitzonen gerechnet werden. Placebo ist dasselbe Verfahren zu Zeitpunkten, an denen die untersuchte Ursache nicht vorliegt. R ist das Ergebnis eines Trades in Risikoeinheiten (−1 R = ein Verlust in Höhe des Abstands zum Stop). M5 sind Fünfminutenkerzen. Die Sommerzeit beginnt und endet in den USA und in Europa an verschiedenen Tagen.

Die Annahme, die niemand prüft

Die Handelsplattform speichert bei jeder Kerze Datum und Uhrzeit als Anzahl der Sekunden seit dem 1. Januar 1970, also im selben Format wie die echte Weltzeit. Naheliegend ist daher die Annahme, dass es sich um UTC handelt. In den Daten aus dem Terminal stehen jedoch die Ziffern der Wanduhr des Broker-Servers, so beschriftet, als wären sie UTC. Kein Programm meldet dabei einen Fehler. Die Zahl sieht korrekt aus, das Datum stimmt, verschoben sind nur die Stunden.

Bei unserem Broker läuft der Server nach der Regel „New York + 7 Stunden“. Das ist eine verbreitete Konvention: Mitternacht auf dem Server fällt auf 17:00 Uhr in New York, wenn der Handelstag am Devisenmarkt endet, und die Woche hat daher fünf Tageskerzen, ohne kurze Sonntagskerze. Im Winter ergibt das UTC+2, im Sommer UTC+3, und die Zeitumstellung erfolgt zusammen mit den USA, nicht mit Europa.

In einem einzigen Test können vier Uhren aufeinandertreffen:

• die Uhr des Broker-Servers, in der die Kerzen und Ticks vorliegen;
• die echte Weltzeit UTC, in der Börsendaten, externe Kalender und die Systemuhr laufen;
• die Zeitzone des Computers, auf dem das Programm läuft (bei uns mitteleuropäische Zeit);
• der im Terminal eingebaute Wirtschaftskalender, der bei uns die Uhrzeiten das ganze Jahr über in festem UTC+3 speichert und deshalb im Winter eine Stunde „später“ ist als die Kerzen.

Auch für einen Trader in Mitteleuropa ist der Abstand nicht konstant. Den größten Teil des Jahres geht der Server der mitteleuropäischen Zeit eine Stunde voraus, aber während 3–4 Wochen im Jahr (im März sowie um den Wechsel von Oktober zu November), wenn die USA und Europa unterschiedliche Zeiten haben, beträgt der Abstand zwei Stunden. Der US-Arbeitsmarktbericht erscheint immer um 8:30 Uhr in New York und um 15:30 Uhr auf der Serveruhr, in Mitteleuropa aber mal um 14:30 und mal um 13:30 Uhr.

Wie es ans Licht kam

Test des Ausbruchs aus der Eröffnungsspanne auf Gold (22.09.2026). Wir beschreiben ihn in Kapitel 10. Die Sessions hatten wir in UTC festgelegt: London ab 8:00 Uhr, New York ab 13:30 Uhr. Der erste Durchlauf behandelte die Kerzenzeit wie UTC. Die New Yorker Session ergab in sechs Jahren 3 Trades, das Placebo, also dieselbe Regel auf einer Spanne ab 16:30 Uhr, dagegen 127. Wenn das Placebo vierzigmal „aktiver“ ist als das Signal, liegt das Problem in der Messung und nicht im Markt.

Die Erklärung war einfach. Unser „13:30 UTC“ war in Wirklichkeit 13:30 Uhr auf der Serveruhr, also 6:30 Uhr in New York und 12:30 Uhr mitteleuropäischer Zeit: eine ruhige Zeit vor der Eröffnung in Amerika, mit engen Spannen, die den Breitenfilter fast nie passierten. 16:30 Uhr auf der Serveruhr dagegen entspricht genau 9:30 Uhr in New York, also der Eröffnung der dortigen Aktienbörse. Das Placebo traf also die echte Eröffnung, das „Signal“ dagegen die Stille davor. Verraten hat den Fehler eine Kontrolle, die wir seitdem bei jedem sessionbezogenen Test durchführen: Die Volatilitätsspitze bei Gold lag nach Serveruhr um 16:00 Uhr, nach Umrechnung in UTC um etwa 14:00 Uhr, also in der Zeit der Datenveröffentlichungen und der Handelseröffnung in New York.

Test der Überraschung bei Makrodaten (17.09.2026, Fehler gefunden am 27.10.). Wir beschreiben ihn in Kapitel 26. Der Kalender aus dem Terminal speichert die Uhrzeiten in festem UTC+3. Im Sommer stimmt das mit den Kerzen überein, im Winter nicht mehr. Der US-Arbeitsmarktbericht erscheint immer um 15:30 Uhr auf der Serveruhr, in unserer Datei stand er im Januar, im Februar und Anfang März jedoch um 16:30 Uhr. Bei 39 von 90 Ereignissen der Lernstichprobe haben wir also ein Fenster gemessen, das eine Stunde nach der Veröffentlichung begann. Die Uhrzeitkontrolle vor dem Test ergab 19 Übereinstimmungen von 19, umfasste aber nur August und September. Im vollständigen Kalenderabzug der Jahre 2017–2026 stand derselbe Bericht vor der Korrektur ganze 80-mal um 16:30 Uhr, nach der Korrektur in 115 von 116 Fällen um 15:30 Uhr.

Automat zum Scalping von Veröffentlichungen (20.08.2026). Er lief im Beobachtungsmodus, ohne Orders. Er verglich die Uhrzeiten aus dem Kalender, die in Serverzeit gespeichert waren, mit der Uhr des Computers, die eine Stunde nachging. Er schaltete sich also genau eine Stunde nach der Veröffentlichung scharf. Bemerkt hat das der Eigentümer des Systems: Der Automat schaltete sich um 15:30 Uhr scharf, die Daten waren um 14:30 Uhr erschienen.

Bevor der Fehler ans Licht kam, hatten sich vier „verspätete“ Beobachtungen als profitabel erwiesen. Daraus entstand die Hypothese, dass der Markt eine Stunde nach den Daten die Bewegung fortsetzt. Wir haben sie mit vor dem Test festgelegten Kriterien geprüft, an 120 Ereignissen und auf zwei Instrumenten. Ein Einstieg eine Stunde nach der Veröffentlichung ergab im Schnitt −0,15 R auf Gold und −0,31 R auf Bitcoin, also schlechter als das Placebo zwei Stunden vor der Veröffentlichung (−0,06 R bzw. +0,03 R). Die vier profitablen Beobachtungen waren schlicht Glück. Beim Schreiben dieses Kapitels haben wir in jenem Test einen kleineren Fehler derselben Familie gefunden. Die Ereignisse wurden über eine europäische Zeitzone umgerechnet, sodass 10 von 120 (die aus den Wochen zwischen der Zeitumstellung in den USA und in Europa) eine Stunde vor dem richtigen Zeitpunkt landeten. An der Schlussfolgerung ändert das nichts, aber es zeigt gut, wie hartnäckig dieser Fehler ist.

Unsere eigene Regel (25.09.2026). Nach dem Test vom 22.09. haben wir in unseren Grundsätzen festgehalten, dass wir die Serveruhr über die Athener Zeitzone umrechnen, also UTC+2 oder UTC+3 mit europäischer Zeitumstellung. Drei Tage später haben wir die stündlichen Kursänderungen von Gold beim Broker mit dem Gold-Terminkontrakt verglichen, dessen Zeit die Börse in echtem UTC angibt, und zwar auf rund 38.000 Stunden aus den Jahren 2020–2026. Im März, Oktober und November brachte die Regel „New York + 7 h“ beide Reihen deutlich besser zur Deckung (Median der Abweichung 0,18 gegenüber 0,28), in den übrigen Monaten schnitten beide Varianten gleich ab. Unsere Regel lag also an 21–28 Tagen im Jahr um eine Stunde daneben; 2026 waren das der 8.–28. März und der 25.–31. Oktober.

Ergebnis: neun Fehler derselben Familie

Zwei Fälle aus der Tabelle veränderten das Testergebnis so stark, dass seine Schlussfolgerung nicht mehr gültig war (17.09. und der erste Durchlauf vom 22.09.). Zwei betrafen das laufende System: die Tagesabrechnung (28.07.) und das Schließen von Positionen vor dem Wochenende (30.08.). Die übrigen haben wir abgefangen, bevor sie eine Entscheidung beeinflussten, aber ausschließlich deshalb, weil etwas merkwürdig aussah.

Warum dieser Fehler wiederkommt

Er löst keine Ausnahme aus. Das Programm läuft, die Zahlen sind plausibel, die Sessions existieren, sie liegen nur an der falschen Stelle. Das Ergebnis einer verschobenen Session ist nicht absurd, es ist einfach das Ergebnis einer anderen Strategie.

Er steckt oft in einer Jahreszeit, die nicht geprüft wurde. Der Kalenderfehler trat nur im Winter auf, die Kontrolle umfasste aber den Sommer. Der Fehler mit der Athener Zeitzone dauert 3–4 Wochen im Jahr. Die Prüfung eines einzelnen Tages oder eines einzelnen Monats erwischt das nicht.

Die Korrektur ist manchmal nur teilweise. Nach der Korrektur vom 20.08. berechnete der Automat „jetzt“ in der europäischen Zeitzone, ab Ende Oktober hätte er sich also wieder eine Stunde nach den Daten scharf geschaltet (abgefangen am 06.10.), und der am selben Tag geschriebene Test verschob 10 von 120 Ereignissen. Die Regel vom 22.09. behob den Fehler von 2–3 Stunden, ließ aber für einige Wochen im Jahr einen Fehler von einer Stunde bestehen. Jedes Mal hielten wir das Thema für erledigt.

Das Wissen wurde nicht zur Regel. Dass die Zeit aus dem Terminal die als UTC beschriftete Serveruhr ist, wussten wir seit Juli. Der Bericht zu einem der Tests vom 14.08. sagte das ausdrücklich, und jener Test rechnete korrekt. Dieses Wissen blieb jedoch in einem einzelnen Bericht und gelangte nicht in die Liste der Grundsätze, sodass wir am 22.09. denselben Fehler von Neuem begingen und ihn ein zweites Mal „entdeckten“. Seit diesem Tag gilt bei uns der Grundsatz: Eine Lehre aus einem Bericht kommt auf die Liste der Regeln, oder sie geht verloren.

Die Kontrolle der Volatilitätsspitze erkennt große Fehler, aber keine kleinen. Eine in UTC über die ganze Stichprobe berechnete Spitze, Sommer und Winter zusammen, liegt auch dann an der richtigen Stelle, wenn die Uhr einige Wochen im Jahr um eine Stunde danebenliegt. Eine Verschiebung um 2–3 Stunden sieht man sofort. Eine Stunde, die nur einen Teil des Jahres betrifft, sieht man erst in einer Kontrolle, die für jede Jahreszeit getrennt durchgeführt wird.

Die Lehre für dich

Wenn deine Strategie irgendetwas mit der Uhrzeit zu tun hat (Session, Eröffnung, Datenveröffentlichung, „nachts handle ich nicht“), ist die Uhr der erste Verdächtige, noch bevor du das Ergebnis bewertest.

So prüfst du die Uhr bei dir:

1. Vergleiche die Uhrzeit der aktuellen Kerze mit echtem UTC von einer beliebigen zuverlässigen Internetuhr. Mach das jetzt und noch einmal nach der Zeitumstellung in den USA und in Europa.
2. Suche die Volatilitätsspitze getrennt für Sommer und Winter, in New Yorker Zeit. Berechne die durchschnittliche Spanne einer M5-Kerze in jedem Halbstundenfenster. Bei Gold und US-Indizes sollte die Spitze in beiden Jahreszeiten zwischen 8:30 und 10:00 Uhr New Yorker Zeit liegen. In einem unserer späteren Tests zeigte eine ähnliche Messung (Anzahl der Ticks), getrennt für Sommer und Winter durchgeführt, die Aktivitätsspitze zur Eröffnung der US-Indizes um 16:30 Uhr Serverzeit in beiden Jahreszeiten, also genau dort, wo sie liegen sollte.
3. Nutze ein bekanntes Ereignis als Referenz. Der US-Arbeitsmarktbericht erscheint immer um 8:30 Uhr in New York. Prüfe einige Termine im Winter, im Sommer und in den Wochen zwischen den Zeitumstellungen.
4. Behandle Kalender und Chart als zwei verschiedene Quellen. Wenn eine Veröffentlichung im Kalender zwischen den Jahreszeiten um eine Stunde „wandert“, liegen Kalender und Kerzen in verschiedenen Zeitzonen, und das eine muss in das andere umgerechnet werden.
5. Lege Sessions in der Ortszeit der Börse fest, mit deren Zeitumstellung. Eine für das ganze Jahr festgelegte UTC-Uhrzeit ergibt in der Praxis zwei verschiedene Sessions, eine im Sommer und eine im Winter.
6. Gib in jeder Datenabfrage die Zeitzone ausdrücklich an, lass dir nach dem Abruf den ersten und den letzten Zeitstempel der Daten ausgeben und vergleiche sie mit dem erwarteten Fenster.
7. Wenn eine Fallzahl merkwürdig aussieht, prüfe zuerst die Uhr. Ein Signal mit 3 Trades neben einem Placebo mit 127 ist das Symptom eines Messfehlers und keine Eigenschaft des Marktes.

Notiere im Trading-Tagebuch die Uhrzeiten deiner Trades in einer einzigen, benannten Zeitzone, zum Beispiel in mitteleuropäischer Zeit oder in UTC, und vermerke, in welcher. Ohne das ist ein Vergleich der Ergebnisse mit Sessions oder Veröffentlichungszeiten eine Messung an der falschen Stelle. Der Rechner „Glück oder Vorteil?“ hilft dir danach einzuschätzen, ob der Unterschied zwischen den Sessions über den Zufall hinausgeht.

Bildungsinhalt, keine Anlageberatung. Vergangene Ergebnisse sind keine Garantie für künftige. Wir beschreiben Fehler in unseren Tests und in unserem System, auf Basis unserer Daten und bei unserem Broker; die Konvention der Serveruhr kann bei einem anderen Broker anders sein.