Eine Automatisierung, die technisch fehlerfrei läuft, kann trotzdem das Falsche tun: Die Terminerinnerung geht eine Stunde zu spät raus, der Tagesbericht zählt den Vortag mit, der Export wird wegen eines falschen Datumsformats abgewiesen. Datum und Uhrzeit sind eine der häufigsten stillen Fehlerquellen in Workflows – gerade weil nichts abstürzt. In diesem Artikel zeige ich Ihnen, wie n8n mit Datumswerten und Zeitzonen umgeht und an welchen Stellen es regelmäßig schiefgeht.
Warum Datum in Automatisierungen so oft kippt
Ein Datum sieht harmlos aus, ist aber selten eindeutig. Steht in einer Zelle „06.07.2026“, ist das der 6. Juli oder – amerikanisch gelesen – der 7. Juni? Ist „14:00“ nach Berliner Zeit gemeint, nach UTC oder nach der Zeitzone des Servers, auf dem der Workflow läuft? Sobald zwei Systeme zusammenspielen – Ihre CRM-Datenbank, eine API, eine Tabelle, ein Buchhaltungsexport – treffen fast immer zwei Datumsformate und potenziell zwei Zeitzonen aufeinander.
Dazu kommt eine technische Eigenheit von n8n, die man kennen muss: n8n reicht Datumswerte zwischen den einzelnen Bausteinen (Nodes) als Zeichenkette weiter, nicht als echtes Datumsobjekt. Laut n8n-Dokumentation müssen Sie einen solchen String erst wieder in ein Datum umwandeln, bevor Sie damit rechnen. Wer das überspringt und einfach „irgendwie“ mit dem Wert arbeitet, bekommt unvorhersehbare Ergebnisse.
Die Standard-Zeitzone von n8n ist nicht Ihre
Das ist die Falle, die mir in Gesprächen mit Betrieben am häufigsten begegnet – und die am schnellsten zu beheben ist. Eine selbst gehostete n8n-Instanz rechnet standardmäßig nicht in mitteleuropäischer Zeit.
Eine frisch installierte n8n-Instanz arbeitet standardmäßig in der Zeitzone America/New_York, nicht in Ihrer. Wer das nicht umstellt, bekommt Zeitpläne, Zeitstempel und Fristen um mehrere Stunden verschoben – und merkt es oft erst, wenn eine Terminerinnerung zur falschen Zeit rausgeht. Der erste Handgriff jeder Automatisierung mit Datum ist deshalb: die Zeitzone setzen.
Konkret: Die Standard-Zeitzone ist America/New_York, und der Schedule-Trigger nutzt genau diesen Wert, um zu entscheiden, wann ein Workflow startet. Ein Zeitplan „jeden Morgen um 8 Uhr“ feuert damit nach New Yorker Zeit – im Sommer also um 14 Uhr bei uns. Sie stellen die Zeitzone an zwei Stellen richtig:
- Für die ganze Instanz über die Umgebungsvariable
GENERIC_TIMEZONE, zum BeispielGENERIC_TIMEZONE=Europe/Berlin. Das ist der empfohlene Weg, wenn der ganze Betrieb in einer Zeitzone arbeitet. - Für einen einzelnen Workflow über die Workflow-Einstellungen (Feld „Timezone“). Das ist praktisch, wenn ein bestimmter Ablauf bewusst in einer anderen Zeitzone laufen soll als der Rest.
Wenn Sie n8n Cloud statt einer eigenen Installation nutzen, setzen Sie die Zeitzone ebenfalls in den Workflow- beziehungsweise Instanz-Einstellungen – die Umgebungsvariable erreichen Sie dort nicht direkt.
Luxon: die Datums-Bibliothek unter der Haube
Für alle Datumsrechnungen setzt n8n auf die JavaScript-Bibliothek Luxon. Zwei Abkürzungen stellt n8n dafür in Ausdrücken (Expressions) bereit:
$now– der aktuelle Zeitpunkt, entsprichtDateTime.now().$today– der heutige Tag um Mitternacht, entsprichtDateTime.now().set({ hour: 0, minute: 0, second: 0, millisecond: 0 }).
Wichtig: Luxon respektiert die eingestellte n8n-Zeitzone. Das gewöhnliche JavaScript-Date() tut das laut Dokumentation nicht und ignoriert insbesondere die workflow-spezifische Zeitzone. Faustregel: In n8n rechnen Sie mit Luxon (DateTime), nicht mit new Date().
Eine zweite Stolperstelle betrifft die Ausgabe als Text. {{ $now }} allein zeigt einen sauberen ISO-Zeitstempel wie 2026-07-08T09:29:34.065+02:00. Sobald Sie das Datum aber per + an einen anderen Text hängen, kippt es in einen Unix-Zeitstempel:
{{ $now }}
// zeigt 2026-07-08T09:29:34.065+02:00
{{ "Erstellt am: " + $now }}
// zeigt "Erstellt am: 1783495774065" – eine rohe Millisekundenzahl
Wer ein lesbares Datum in eine Nachricht einbauen will, formatiert es deshalb vorher ausdrücklich (siehe nächster Abschnitt), statt es einfach anzuhängen.
Datum einlesen, umwandeln und formatieren
Kommt ein Datum als Zeichenkette herein, wandeln Sie es zuerst in ein Luxon-Objekt um. Für Standardformate genügt fromISO, für eigenwillige Formate geben Sie das Muster mit Tokens an:
// Standardformat (ISO 8601)
DateTime.fromISO('2026-07-08')
// beliebiges Format über Tokens beschreiben
DateTime.fromFormat('08-07-2026', 'dd-MM-yyyy')
Für die Ausgabe drehen Sie den Spieß um. toFormat('dd.MM.yyyy') liefert 08.07.2026, toFormat('dd.MM.yyyy HH:mm') ergänzt die Uhrzeit im 24-Stunden-Format. Rechnen ist ebenso direkt: $today.minus({ days: 7 }) gibt das Datum vor einer Woche, $now.plus({ hours: 3 }) drei Stunden später.
Wer lieber klickt als tippt, nutzt den Date & Time-Node. Er bündelt genau diese Aufgaben in benannten Operationen:
| Was Sie tun wollen | Operation im Date & Time-Node |
|---|---|
| Aktuelles Datum holen | Get Current Date (mit Option „Timezone“) |
| In ein anderes Format bringen | Format a Date (Luxon-Tokens oder Vorlagen wie YYYY-MM-DD) |
| Tage/Stunden addieren oder abziehen | Add to a Date / Subtract From a Date |
| Abstand zwischen zwei Daten | Get Time Between Dates |
| Auf Tag/Stunde runden | Round a Date |
Bei „Format a Date“ gibt es die Option „Use Workflow Timezone“, bei „Get Current Date“ das Feld „Timezone“ (leer = Instanz-Zeitzone). Damit steuern Sie bewusst, in welcher Zeitzone das Ergebnis interpretiert wird – statt sich auf einen Zufallswert zu verlassen.
Zeitzonen umrechnen – und die Sommerzeit nicht vergessen
Manchmal müssen Sie ein Datum von einer Zeitzone in eine andere überführen, etwa weil eine API alles in UTC liefert, Ihr Bericht aber Ortszeit zeigen soll. In Luxon macht das setZone:
{{ $now.setZone('Europe/Berlin').toFormat('dd.MM.yyyy HH:mm') }}
Ein Detail entscheidet hier über Erfolg oder stille Fehler: Verwenden Sie benannte Zeitzonen wie Europe/Berlin, nicht feste Verschiebungen wie „UTC+1“. Nur der benannte Eintrag weiß, dass Deutschland im Sommer auf UTC+2 umstellt. Wer stattdessen einen festen Offset einträgt, hat die Hälfte des Jahres eine Stunde daneben – und der Fehler taucht ausgerechnet dann auf, wenn im Frühjahr oder Herbst die Uhren umgestellt werden. Weil solche Fehler nur zu bestimmten Jahreszeiten sichtbar werden, ist die Automatisierung vor dem Go-live gründlich zu testen – am besten auch mit Datumswerten rund um eine Zeitumstellung.
Drei Fallen, die immer wieder auftauchen
Zum Abschluss die Muster, die in der Praxis am häufigsten für falsche Zeiten sorgen:
Datum als Seriennummer statt als Datum
Tabellenprogramme geben Datumswerte gern als fortlaufende Zahl heraus. Der Google-Sheets-Trigger in n8n etwa liefert Datums- und Zeitwerte per Voreinstellung als Seriennummer statt als lesbares Datum. Wer damit rechnet, ohne es zu wissen, bekommt Unsinn. Wie Sie Tabellen als Datenquelle sauber anbinden, habe ich in einem eigenen Beitrag beschrieben.
Format-Mismatch beim Export
Buchhaltungs- und Lohnsysteme sind bei Datumsformaten pingelig. Erwartet der Import TT.MM.JJJJ und Sie liefern JJJJ-MM-TT, wird die Datei abgewiesen oder – schlimmer – falsch eingelesen. Definieren Sie das Zielformat einmal explizit über toFormat, statt sich auf die Standardausgabe zu verlassen. Ein einheitliches Datumsformat gehört ohnehin zur Datenqualität vor der Automatisierung.
String und Datum verwechselt
Weil n8n Datumswerte zwischen Nodes als Text weitergibt, sehen zwei Werte im Editor gleich aus, verhalten sich aber unterschiedlich: Der eine ist ein echtes Luxon-Objekt, der andere nur seine Textdarstellung. Rechnen können Sie nur mit dem Objekt. Im Zweifel wandeln Sie den Wert mit fromISO oder fromFormat zurück, bevor Sie ihn weiterverarbeiten.
Fazit
Datumsfehler sind selten spektakulär – sie schleichen sich ein und fallen erst auf, wenn eine Frist verpasst oder ein Termin verschoben ist. Die gute Nachricht: Die meisten lassen sich mit drei Handgriffen vermeiden. Setzen Sie die Zeitzone bewusst (nicht New York), rechnen Sie konsequent mit Luxon statt mit rohem JavaScript, und formatieren Sie Ein- und Ausgabe ausdrücklich. Wenn Sie einen Workflow planen, in dem Termine, Fristen oder zeitgesteuerte Abläufe eine Rolle spielen, schaue ich mir das gern im kostenlosen Prozess-Check mit Ihnen an – und wenn Sie tiefer in die Werkzeugkette einsteigen wollen, finden Sie in meiner n8n-Beratung den passenden Rahmen. Es ist meist eine Kleinigkeit, die den Unterschied zwischen „läuft“ und „stimmt“ macht.