OpenClaw Main Fixes Zoned Cron Times and Advanced Delivery Route Loss

OpenClaw has merged three cron corrections for two places where intent could silently drift: parsing a scheduled instant and round-tripping an advanced delivery route through an editor.

One fix normalizes zoned ISO timestamps and end-of-day forms consistently. Two others preserve advanced delivery settings when a job is cloned in the Control UI or edited in the macOS app.

These changes landed after 2026.7.2-beta.7.

A timestamp must resolve to one intended instant

PR #117969 fixes timezone handling for ISO timestamps and end-of-day times. The risk is not merely a rejected string. Inconsistent normalization can turn a human’s local intent into a different UTC instant, or make equivalent forms behave differently across create, edit and reload paths.

Operators should treat stored UTC time, original timezone intent and next-run preview as three pieces of evidence. If only the formatted label is checked, a schedule can look plausible while pointing at the wrong instant.

End-of-day forms deserve explicit testing because 24:00 means the boundary at the start of the following calendar day, not an extra hour inside the current one.

Editors must round-trip fields they do not simplify

PR #117909 fixes cloning in the web Control UI so advanced delivery settings survive. PR #118047 closes the corresponding macOS editor path where advanced delivery routes could be dropped during edit and save.

This is a classic partial-form hazard: an editor loads a richer object than it displays, then serializes only the fields it understands. The user changes a label or schedule and unintentionally deletes delivery metadata they never touched.

Interpretation: an editor that cannot display an advanced field must preserve it losslessly or refuse the edit. Silently discarding it is data loss.

Who should act

Prioritize a containing build if you:

• create one-shot jobs from zoned ISO timestamps;
• use end-of-day schedule forms;
• operate outside UTC or around daylight-saving transitions;
• clone jobs with webhook, account, thread or other advanced delivery metadata; or
• edit cron jobs from both CLI and macOS/web surfaces.

Acceptance matrix

Use disposable jobs whose payload records a unique identity without external side effects:

Do not point test jobs at production recipients. A timezone acceptance test should write to an isolated local target or disposable endpoint.

Reconcile existing jobs

For jobs created or edited on older builds:

1. export the canonical job definition through a supported read path;
2. calculate the expected UTC instant independently;
3. compare next-run time, timezone and delivery route;
4. inspect recent run history for an offset or missing destination;
5. repair one canonical copy; and
6. clone or edit only after a containing build passes the round-trip test.

If an old job appears not to have delivered, do not replay it until execution history and recipient evidence show whether the payload ran elsewhere or at another time.

Evidence and limits

The official merged PR and documentation records establish the timezone-normalization and editor round-trip fixes. OpenClaw Academy did not schedule a live job across a timezone boundary or use the macOS editor. The source records describe advanced route preservation broadly; operators should compare every field their deployment uses rather than assuming a named subset.

Bottom line

Cron correctness requires both temporal and delivery fidelity. Stage a containing build, prove the timestamp resolves to the intended instant, then clone and edit the job and prove every advanced route survives untouched.