← Alle Insights
11 Min. Lesezeit · Execution · Oktober 2026

Zeitumstellung im Trading-Bot die Lücke zwischen EU und USA.

Wenn Ihr Trading-Bot nach der Zeitumstellung eine Stunde zu früh oder zu spät handelt, steckt fast immer eine fest eingetragene Ortszeit dahinter. 2026 stellt die EU am 25. Oktober auf Normalzeit zurück, die USA erst am 1. November; vom 26. bis 30. Oktober liegen Frankfurt und New York deshalb nur fünf statt sechs Stunden auseinander, und die New Yorker Börse öffnet um 14:30 Uhr deutscher Zeit statt um 15:30 Uhr. Wer Sessions als „15:30 bis 22:00 Uhr“ hinterlegt hat, verpasst in dieser Woche die erste Handelsstunde, ohne dass eine Fehlermeldung erscheint. Dieser Artikel zeigt, wie Sie das dauerhaft lösen: intern mit UTC rechnen, Handelszeiten über IANA-Zeitzonen definieren, die Serverzeit Ihres Brokers prüfen, den MQL5-Fallstrick mit TimeGMT() im Strategy Tester kennen und die Umstellungswochen gezielt testen. Stand Oktober 2026.

Wann wird 2026 umgestellt und warum entsteht eine Lücke?

In der EU regelt die Richtlinie 2000/84/EG die Sommerzeit: Sie endet am letzten Sonntag im Oktober um 01:00 Uhr UTC, und zwar in allen Mitgliedstaaten gleichzeitig. 2026 ist das der 25. Oktober; in Deutschland springt die Uhr von 03:00 auf 02:00 Uhr zurück. Großbritannien stellt nach eigenem Recht, aber zum selben Zeitpunkt um.

In den USA legt 15 U.S.C. § 260a fest, dass die Sommerzeit am ersten Sonntag im November um 2 Uhr Ortszeit endet. 2026 ist das der 1. November. Weil jede US-Zeitzone zu ihrer eigenen Ortszeit umstellt, wechselt New York um 06:00 UTC, Chicago eine Stunde später. Dazwischen liegt eine Woche, in der Europa schon Normalzeit hat und die USA noch Sommerzeit. Im Frühjahr ist die Lücke länger: Nach den aktuellen Regeln stellen die USA am 14. März 2027 vor, die EU erst am 28. März 2027.

Die folgende Tabelle zeigt den Abstand wichtiger Handelsplätze zur deutschen Zeit, berechnet mit der IANA-Zeitzonendatenbank:

Handelsplatz (Zeitzone)bis 24.10.202626.–30.10.2026ab 02.11.2026
New York (America/New_York)−6 Std.−5 Std.−6 Std.
Chicago (America/Chicago)−7 Std.−6 Std.−7 Std.
London (Europe/London)−1 Std.−1 Std.−1 Std.
Tokio (Asia/Tokyo, keine Sommerzeit)+7 Std.+8 Std.+8 Std.
Sydney (Australia/Sydney, Sommerzeit seit 04.10.)+9 Std.+10 Std.+10 Std.

Für US-Aktien heißt das konkret: Die reguläre Handelszeit der NYSE läuft von 9:30 bis 16:00 Uhr New Yorker Zeit. In UTC sind das bis zum 31. Oktober 13:30 bis 20:00 Uhr, ab dem 2. November 14:30 bis 21:00 Uhr. In deutscher Zeit beginnt der Handel bis zum 23. Oktober um 15:30 Uhr, vom 26. bis 30. Oktober um 14:30 Uhr und ab dem 2. November wieder um 15:30 Uhr.

Typische Fehler in der Umstellungswoche.

Zeitfehler sind tückisch, weil der Bot formal korrekt weiterläuft. Er handelt nur zur falschen Stunde, und das fällt oft erst beim Blick auf die Auswertung auf. Typische Muster aus der Praxis automatisierter Systeme:

Wie sich solche Fehler in die übrigen Schnittstellenprobleme einreihen, beschreibt der Artikel zu API-Edge-Cases bei Brokern. Dieser Artikel vertieft den Sonderfall Zeitumstellung.

Grundregel: intern UTC, Sessions über IANA-Zeitzonen.

UTC (koordinierte Weltzeit) kennt keine Sommerzeit. Wenn Ihr System alle Zeitstempel in UTC speichert und vergleicht, gibt es keine doppelten oder fehlenden Stunden. Ortszeit brauchen Sie nur an zwei Stellen: bei der Anzeige für Menschen und bei der Definition von Handelszeiten, denn eine Börse öffnet nach ihrer eigenen Ortszeit, nicht nach UTC.

Für die Umrechnung nutzen Sie die IANA-Zeitzonendatenbank (auch „tz database“), die Zeitzonen über Namen wie „America/New_York“ oder „Europe/Berlin“ samt aller historischen und geplanten Umstellungen abbildet. In Python steht dafür seit Version 3.9 das Modul zoneinfo in der Standardbibliothek. Es nutzt die Zeitzonendaten des Systems und weicht auf das PyPI-Paket tzdata aus, wenn das System keine mitbringt. Die Python-Dokumentation empfiehlt, tzdata als Abhängigkeit einzutragen, wenn der Code plattformübergreifend laufen soll, etwa unter Windows.

from datetime import datetime, time
from zoneinfo import ZoneInfo

NEW_YORK = ZoneInfo("America/New_York")
US_OPEN, US_CLOSE = time(9, 30), time(16, 0)

def in_us_cash_session(ts_utc: datetime) -> bool:
    """Prüft die reguläre US-Handelszeit. Feiertage fehlen bewusst."""
    if ts_utc.tzinfo is None:
        raise ValueError("naiver Zeitstempel ohne Zeitzone")
    local = ts_utc.astimezone(NEW_YORK)
    return local.weekday() < 5 and US_OPEN <= local.time() < US_CLOSE

Die Funktion bekommt einen UTC-Zeitstempel und rechnet ihn erst für den Vergleich in New Yorker Zeit um. Damit stimmt sie vor, während und nach der Lücke, ohne dass jemand im Oktober etwas anpassen muss. Naive Zeitstempel ohne Zeitzone lehnt sie bewusst ab, statt stillschweigend die Ortszeit des Rechners anzunehmen.

Für doppelte Ortszeiten kennt zoneinfo das Attribut fold: Mit fold=0 gilt der Offset vor der Umstellung, mit fold=1 der danach. 02:30 Uhr am 25.10.2026 in Berlin ist also entweder 00:30 oder 01:30 UTC. Wer intern konsequent UTC speichert, muss diese Mehrdeutigkeit nur bei Eingaben von Menschen auflösen. Wenn Sie Python-Strategien mit KI-Assistenten entwickeln, gehört diese Regel ausdrücklich in die Projektvorgaben, sonst erzeugen Assistenten leicht naive datetime.now()-Aufrufe.

Broker-Serverzeit verstehen und beim eigenen Broker prüfen.

Bei MetaTrader 5 tragen Kerzen und Ticks die Zeit des Handelsservers, nicht UTC und nicht die Zeit Ihres Rechners. Welche Zeitzone ein Broker für seinen Server wählt und ob und nach welchem Kalender er Sommerzeit anwendet, ist brokerabhängig. Manche Broker orientieren sich am europäischen, andere am US-Kalender. Verlassen Sie sich hier nicht auf Forenangaben, sondern prüfen Sie Ihren Broker.

So gehen Sie vor:

  1. In den Unterlagen oder beim Support nachfragen, welche Serverzeitzone gilt und zu welchem Datum umgestellt wird.
  2. Den Offset live messen: Die Differenz aus TimeTradeServer() und TimeGMT() ergibt den aktuellen Abstand der Serverzeit zu UTC. Beide Werte werden im Terminal aus der Uhr und den Zeiteinstellungen des Rechners berechnet. Uhrzeit und Zeitzone des Rechners oder VPS müssen deshalb stimmen, am besten mit automatischer Zeitsynchronisierung.
  3. Den Offset täglich protokollieren, besonders vom 24. Oktober bis 2. November. Sie sehen dann direkt, wann Ihr Broker tatsächlich umstellt.
  4. Historische Daten prüfen: Verschiebt sich die Uhrzeit, zu der eine Börse regelmäßig öffnet, in den Serverzeit-Kerzen an bestimmten Tagen um eine Stunde, kennen Sie die Umstellungsregel des Servers.

Bei Python-Anbindungen an Broker-APIs gilt dasselbe in anderer Form: Lesen Sie in der Doku nach, ob Zeitstempel in UTC, in Börsenzeit oder in der Zeitzone des Kontos geliefert werden, und wandeln Sie sie direkt beim Empfang in zeitzonenbewusste UTC-Werte um.

MQL5-Fallstrick: TimeGMT() und TimeTradeServer() im Strategy Tester.

Live ist die Messung über TimeTradeServer() − TimeGMT() ein brauchbarer Weg. Im Strategy Tester funktioniert sie nicht. Laut MQL5-Dokumentation wird TimeTradeServer() im Tester aus den historischen Daten simuliert und ist immer gleich TimeCurrent(). Und TimeGMT() ist im Tester immer gleich dieser simulierten Serverzeit. Die Differenz ist im Backtest also immer null.

Die Folge: Ein Expert Advisor, der Sessions über einen gemessenen GMT-Offset berechnet, rechnet im Backtest so, als liefe der Server auf UTC. Seine Handelsfenster verschieben sich um genau den Abstand, den die Serverzeit Ihres Brokers tatsächlich zu UTC hat, und die Ergebnisse beschreiben eine andere Strategie als die, die live läuft. Weil kein Fehler gemeldet wird, fällt das oft erst beim Vergleich von Backtest- und Live-Trades auf.

int ServerUtcOffsetSec()
  {
   if(MQLInfoInteger(MQL_TESTER))
      return OffsetFromBrokerRule(TimeCurrent()); // eigene Funktion, siehe Text
   long diff = (long)(TimeTradeServer() - TimeGMT());
   return (int)(MathRound(diff / 1800.0) * 1800); // auf halbe Stunden runden
  }

Im Tester muss der Offset deshalb aus einer eigenen Regel kommen, etwa einer Funktion OffsetFromBrokerRule(), die anhand des Datums und der geprüften Umstellungsregel Ihres Brokers den Abstand zu UTC liefert. Diese Regel ist eine Annahme, die Sie gegen die Live-Messung aus dem vorigen Abschnitt abgleichen sollten. Weitere Stabilitätsregeln für Expert Advisors finden Sie in den MQL5-Praxis-Tipps.

Backtests und Testfälle für die Umstellungswochen.

Zeitlogik lässt sich gut automatisiert testen, weil die Umstellungsdaten bekannt sind. Sinnvoll sind Testfälle direkt vor, in und nach der Lücke sowie jeweils eine Minute vor und nach Sessionbeginn. Für die Python-Funktion von oben könnte das so aussehen:

import pytest
from datetime import datetime, timezone

from sessions import in_us_cash_session  # Funktion von oben

U = timezone.utc

@pytest.mark.parametrize("ts, erwartet", [
    (datetime(2026, 10, 23, 13, 30, tzinfo=U), True),   # Fr, 15:30 MESZ
    (datetime(2026, 10, 26, 13, 30, tzinfo=U), True),   # Mo, 14:30 MEZ (Lücke)
    (datetime(2026, 10, 26, 13, 29, tzinfo=U), False),  # eine Minute davor
    (datetime(2026, 11, 2, 13, 30, tzinfo=U), False),   # Mo, 14:30 MEZ, NY 08:30
    (datetime(2026, 11, 2, 14, 30, tzinfo=U), True),    # Mo, 15:30 MEZ
])
def test_us_session(ts, erwartet):
    assert in_us_cash_session(ts) is erwartet

Darüber hinaus lohnen sich diese Prüfungen:

Die Testfälle sollten Sie in die Testsuite aufnehmen und nicht nur einmal vor der Umstellung laufen lassen. Zeitfehler kommen zurück, sobald jemand eine Hilfsfunktion „vereinfacht“.

Grenzen, Risiken und die offene Frage der US-Sommerzeit.

Auch eine saubere Zeitlogik löst nicht alles. Diese Punkte bleiben eigene Aufgaben:

Ein offener Punkt betrifft die USA selbst. Das Repräsentantenhaus hat den Sunshine Protection Act, der die Sommerzeit dauerhaft machen würde, am 14. Juli 2026 mit 308 zu 117 Stimmen verabschiedet. Damit er Gesetz wird, müssen Senat und Präsident zustimmen. Laut amtlichem Bill-Status wurde der Entwurf am 15. Juli 2026 an den Handelsausschuss des Senats überwiesen; nach Medienberichten vom 22. September 2026 war dort keine Abstimmung angesetzt. Eine dauerhafte US-Sommerzeit ist also möglich, aber nicht beschlossen. Ohne Gesetz vor dem 1. November wird wie gewohnt umgestellt. Genau hier zahlt sich die IANA-Datenbank aus: Kommt die Änderung, wird sie dort eingepflegt, und Ihr Code bleibt unverändert, solange Sie die Zeitzonendaten aktuell halten.

Was Sie vor dem 25. Oktober konkret tun können.

Bis zur EU-Umstellung bleiben gut zwei Wochen. Diese Schritte sind in dieser Zeit realistisch:

  1. Code durchsuchen: Nach festen Uhrzeiten, festen Offsets und naiven Zeitaufrufen suchen, in Python etwa datetime.now() ohne Zeitzone, in MQL5 nach Sessionlogik mit Konstanten.
  2. Sessions umstellen: Handelszeiten in der Zeitzone des Marktes definieren und intern mit UTC vergleichen.
  3. Broker prüfen: Serverzeitzone und Umstellungsdatum erfragen, den Offset ab sofort täglich protokollieren.
  4. Tester-Logik trennen: In Expert Advisors den Offset im Strategy Tester nicht aus TimeGMT() ableiten, sondern aus einer geprüften Regel.
  5. Testfälle anlegen: Mindestens die Tage 23.10., 26.10. und 02.11.2026 mit Sessionbeginn als feste Tests.
  6. Umstellungswoche beobachten: Vom 26. bis 30. Oktober Einstiegszeiten täglich gegen die erwarteten UTC-Zeiten abgleichen und im Zweifel einzelne Strategien pausieren.

Wenn ich Trading-Systeme entwickle, gehören Zeitzonentests zu den Abnahmekriterien, so wie Ordertests und Notaus. Wer sein System nicht selbst umbauen möchte, findet unter Trading-Automatisierung beschrieben, wie ich private Trader und Unternehmen bei Umsetzung und Tests unterstütze.

Häufige Fragen.

Wann öffnet die US-Börse während der Zeitumstellung 2026 in deutscher Zeit?

Die NYSE handelt regulär von 9:30 bis 16:00 Uhr New Yorker Zeit. Bis zum 23. Oktober 2026 entspricht das 15:30 Uhr deutscher Zeit. Weil Europa am 25. Oktober umstellt, die USA aber erst am 1. November, öffnet die Börse vom 26. bis 30. Oktober um 14:30 Uhr deutscher Zeit. Ab dem 2. November beginnt der Handel wieder um 15:30 Uhr.

Warum handelt mein Trading-Bot nach der Zeitumstellung eine Stunde zu früh oder zu spät?

Meist sind Handelszeiten als feste Ortszeit oder fester Offset zu UTC hinterlegt, oder die Daten tragen naive Zeitstempel ohne Zeitzone. Bei MetaTrader 5 kommt hinzu, dass Kerzen in der Serverzeit des Brokers vorliegen, die nach einem eigenen Kalender umstellen kann. Abhilfe: intern UTC verwenden, Sessions in der Zeitzone des Marktes definieren und die Serverzeit des eigenen Brokers prüfen.

Warum ist TimeGMT() im MT5 Strategy Tester falsch?

Laut MQL5-Dokumentation ist TimeGMT() im Strategy Tester immer gleich der simulierten Serverzeit TimeTradeServer(), die dort wiederum gleich TimeCurrent() ist. Ein aus der Differenz berechneter GMT-Offset ist im Backtest deshalb immer null. Expert Advisors sollten im Tester den Offset aus einer eigenen, gegen Live-Messungen geprüften Regel für den Broker ableiten.

Wie behandle ich Zeitzonen in Python für Trading richtig?

Speichern Sie alle Zeitstempel zeitzonenbewusst in UTC. Für Handelszeiten nutzen Sie das Modul zoneinfo aus der Standardbibliothek ab Python 3.9 mit IANA-Namen wie America/New_York. Unter Windows empfiehlt die Python-Dokumentation zusätzlich das Paket tzdata. Doppelte Ortszeiten in der Umstellungsnacht lassen sich über das Attribut fold eindeutig zuordnen.

Schaffen die USA die Zeitumstellung 2026 ab?

Das US-Repräsentantenhaus hat den Sunshine Protection Act am 14. Juli 2026 verabschiedet. Damit er gilt, müssen der Senat zustimmen und der Präsident unterschreiben. Seit dem 15. Juli 2026 liegt der Entwurf im Handelsausschuss des Senats; nach Medienberichten vom 22. September 2026 war keine Abstimmung angesetzt. Eine dauerhafte Sommerzeit ist damit nicht beschlossen; ohne neues Gesetz wird am 1. November wie gewohnt auf Normalzeit umgestellt.

Quellen und Stand.

Stand: 7. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen die Zeitlogik Ihres Trading-Bots vor der nächsten Umstellung prüfen und robuster machen lassen? Unverbindlich anfragen — wir klären Code, Broker-Serverzeit und Testfälle für die Umstellungswochen. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.

Verwandte Artikel

Infrastruktur · 6 Min

API-Edge-Cases bei Brokern: was die Doku verschweigt

 MQL5 · 3 Min

MQL5 Praxis-Tipps: stabile Expert Advisors bauen

 KI im Trading · 6 Min

Tick-Daten bereinigen: Bad Prints, Outlier und Zeitstempel-Chaos beherrschen