Zeitzonen, Planung und menschliche Erwartungen

Die meisten Anfänger zerstören Automationen nicht mit schlechter Logik. Sie zerstören sie mit Zeit.

Eine Maschine denkt in UTC. Eine andere zeigt Host-Lokalzeit. Der Nutzer meint "9 Uhr morgens bei mir." Der Cron-Ausdruck meint etwas anderes. Und am Ende schwört jeder, der Zeitplan sei doch eindeutig gewesen.

Genau deshalb fühlen sich Zeitfehler so unerquicklich an. Nichts explodiert. Der Agent macht nur höflich das Falsche zur falschen Uhrzeit.

Die offizielle Date-&-Time-Doku und die Scheduled-Tasks-Doku machen die Kernregel ziemlich klar: OpenClaw trennt Transport-Zeitstempel, User-Kontext und Scheduler-Verhalten absichtlich. Wenn du das alles als eine amorphe Masse namens "Zeit" behandelst, fängt dich der Fehler früher oder später.

Die drei Uhren, mit denen du es wirklich zu tun hast

Ein sauberes Denkmodell hilft mehr als noch ein generischer Cron-Crashkurs. In OpenClaw jonglierst du meist mit drei verschiedenen Zeitflächen.

• Nachrichten-Umschlagzeit: standardmäßig Host-Lokalzeit, außer du überschreibst envelopeTimezone
• User-Kontextzeit: der System Prompt trägt die User-Zeitzone, aber keine Live-Uhr
• Tool- und Provider-Zeit: Payloads behalten provider-native Zeitstempel und ergänzen UTC-Felder wie timestampMs und timestampUtc

Diese Trennung ist kein Design-Unfall. Sie ist Schutz durch saubere Rollen. Transport-Logs brauchen operative Aussagekraft. Das Modell braucht Nutzerkontext. Tool-Payloads sollen nicht so tun, als hätte der Provider etwas anderes geliefert.

Stell dir einen Flughafen vor. Tower, Abflugtafel und SMS an den Passagier reden vielleicht über denselben Flug, aber nicht für dieselbe Zielgruppe. Wenn du das gedankenlos vermischst, verpasst jemand das Boarding.

Wo Zeitzonenfehler tatsächlich entstehen

Die meisten Planungsfehler entstehen an den Übergängen zwischen diesen Flächen, nicht in einer einzelnen von ihnen.

1. Host- gegen User-Zeitzone: der Gateway-Host lebt in einer anderen Region als der Mensch, für den geplant wird
2. Angezeigte Zeit gegen geplante Zeit: die Logs sehen für den Operator richtig aus, aber der Trigger feuert in einer anderen Zone
3. Provider-Zeit gegen lokale Interpretation: Tool-Payloads behalten rohe Zeitstempel, also zählt die nachgelagerte Darstellung
4. Menschliche Sprache gegen Cron-Syntax: "jeden Montag um 9" ist etwas anderes als eine halb erinnerte Cron-Zeile

Genau hier kippen menschliche Erwartungen. Ein Nutzer interessiert sich nicht dafür, dass die Infrastruktur intern konsistent war. Er interessiert sich dafür, dass "morgen früh" nicht um 3 Uhr nachts angekommen ist.

Cron-Timing ist nicht automatisch menschlich lokal

Das ist der Punkt, den Operatoren gern überspringen, weil er zu banal wirkt. Leider ist er wichtig.

OpenClaw-Cron unterstützt Einmal-Zeitstempel, feste Intervalle und Cron-Ausdrücke. Für Cron-Ausdrücke kannst du --tz setzen, um Wall-Clock-Planung an eine echte Zeitzone zu binden. Ohne das denkst du oft in Infrastrukturzeit statt in Menschenzeit.

Die Doku sagt auch: Zeitstempel ohne Zeitzone werden als UTC behandelt. Das ist herrlich konsistent und herrlich gefährlich, wenn jemand einen lokal aussehenden Zeitpunkt eintippt und stillschweigend erwartet, dass das System seine Absicht errät.

# explizite lokale Wall-Clock-Planung
openclaw cron create "0 9 * * 1-5"   --name "Weekday morning summary"   --session main   --system-event "Prepare the weekday summary for the user"   --tz Europe/Berlin

# Einmal-Zeitpunkt, explizit UTC
openclaw cron create "2026-06-09T07:00:00Z"   --name "UTC reminder"   --session main   --system-event "Check the deployment report"   --delete-after-run

Wenn der Nutzer lokale Geschäftszeiten meint, sag das dem Scheduler direkt. Verstecke lokale Absicht nicht in einem UTC-artigen Zeitstempel und hoffe, dass Zukunfts-du den Trick noch versteht.

Auch mit richtiger Zeitzone kann dich der Scheduler überraschen

Zeitzonen-Korrektheit ist nur ein Teil der Geschichte. Die Semantik des Schedulers kann trotzdem zuschnappen.

OpenClaw dokumentiert zwei Details, die wichtiger sind, als sie wirken:

• Wiederkehrende Läufe zur vollen Stunde können leicht gestaffelt werden, um Lastspitzen zu glätten
• Tag-des-Monats und Wochentag arbeiten mit OR-Logik, solange du bei Croner nicht bewusst zum strengeren Muster greifst

Gerade der zweite Punkt erwischt Leute ständig. Sie glauben, sie hätten "den 15., falls Montag" geplant. Tatsächlich haben sie "jeden 15. und jeden Montag" geplant. Gleiches Selbstvertrauen. Sehr anderer Kalender.

Es ist ein bisschen so, als würdest du zwei Klingeln an ein Haus bauen und dann überrascht tun, dass beide klingeln können.

# sieht strenger aus, als es ist
0 9 15 * 1

# mit der Standard-Logik von Croner bedeutet das:
# 9:00 an jedem 15.
# plus 9:00 an jedem Montag

Heartbeats und Active Hours haben dasselbe menschliche Problem

Cron ist nicht der einzige Ort, an dem Zeit-Erwartungen schiefgehen. Auch Heartbeats können über Active Hours begrenzt werden, und diese Prüfungen nutzen die konfigurierte Zeitzone.

Das ist wichtig, weil Heartbeat-Verhalten gesprächig wirkt, nicht mechanisch. Wenn ein stiller Check-in nach Mitternacht auftaucht, erlebt der Nutzer das als sozialen Fehltritt, nicht als niedliche Config-Differenz.

Genau hier zahlt sich eine langweilige Betreiber-Gewohnheit aus: Wenn ein Agent zeitgesteuert mit Menschen spricht, prüfe sowohl die Scheduling-Regel als auch die Zeitzone, die diese Regel rahmt. Technische Korrektheit reicht nicht, wenn sich das Verhalten trotzdem falsch anfühlt.

Wie du Zeit für Menschen klar kommunizierst

Menschliche Erwartungen brechen, wenn die Maschine präzise ist, die Formulierung aber schwammig bleibt.

Gute Operatoren tun drei Dinge:

• Die Zeitzone benennen, wenn der Zeitplan wirklich wichtig ist
• Absolute Zeitstempel nutzen für einmalige, heikle Jobs
• Interne Taktung von Nutzerformulierung trennen, damit Logs operativ bleiben und Nachrichten menschlich

Wenn ein Report um 09:00 Europe/Berlin läuft, dann sag das. Wenn eine Erinnerung bei 2026-06-09T07:00:00Z feuert, wandle sie um, bevor du sie einem Menschen zeigst. "Später heute" ist für lockeren Chat okay. Für Audits, Übergaben und wiederkehrende Automationen ist es miserabel.

Eine einfache Sanity-Check-Liste für Zeitpläne

Bevor du einer wiederkehrenden Automation vertraust, geh kurz diese Liste durch:

• User-Zeitzone: ist der Personen-Kontext korrekt gesetzt?
• Envelope-Zeitzone: lesen Operatoren die Zeitstempel in einer sinnvollen Zone?
• Cron-Zeitzone: ist der Job mit --tz gepinnt, wenn Wall-Clock-Absicht wichtig ist?
• Schedule-Semantik: sind OR-Verhalten, Staffelung und Wiederholungslogik verstanden?
• Formulierung für Menschen: sagt die Nachricht dasselbe, was der Scheduler wirklich tun wird?

Wenn diese fünf Dinge zusammenpassen, ist der Zeitplan meist belastbar. Wenn nicht, ist der Fehler oft schon da. Er hat dich nur noch nicht öffentlich blamiert.

Die Kurzfassung

Zeitfehler in OpenClaw sind selten ein einzelnes kaputtes Feature. Sie entstehen, weil Host-Zeit, User-Zeit, Provider-Zeit und Scheduler-Zeit jeweils eine andere Aufgabe haben.

Respektiere diese Trennung. Nutze explizite Zeitzonen für Wall-Clock-Schedules. Halte Logs operativ und Nachrichten menschlich. Prüfe Wiederholungsregeln, bevor du ihnen vertraust. So vermeidest du die langweiligste Klasse von Automationsfehlern, die dummerweise auch zu den teuersten gehört.