The OpenClaw Cron Daylight Saving Playbook

Put every OpenClaw cron job that does bookkeeping (cleanups, syncs, counters, anything that must run exactly once a day) on "tz": "UTC", and keep a local zone such as America/Los_Angeles only for messages a person reads at a fixed hour. Then move every local-time job out of the 1:00 to 2:59 a.m. window, because that hour repeats in November and disappears in March. Interval jobs ("kind": "every") count elapsed time, so the clock change does not touch their spacing.

Clocks in the United States fell back at 2:00 this morning, Sunday, November 1, 2026. Europe did it a week earlier, on October 25. For those seven days London sat seven hours ahead of San Francisco instead of eight, and any job that bridged the two cities was off by an hour without a single error in its log.

I found one of mine this morning. A check I think of as “the 4 a.m. job” is written as 0 11 * * * in UTC, and starting today it runs at 3 a.m. Pacific. Nothing broke. The job is honest about when it runs, and the person who has to remember that the local hour moved is me.

This page is for one machine running the OpenClaw gateway, with jobs in ~/.openclaw/cron/jobs.json and at least one reader who lives in a zone that observes daylight saving.

What the Scheduling Guides Already Get Right

The pages that rank for cron and daylight saving (the CronMonitor guide on dev.to, iTime's cron timezone production checklist, and the long-standing man 8 cron page for Vixie cron on Debian) mostly agree. Schedule machine work in UTC. Store a real IANA zone name like America/New_York instead of an abbreviation such as PST, which is wrong for half the year. Preview the next ten fire times before you deploy, and write down what the job should do on the night an hour repeats and the night an hour vanishes. The iTime checklist also asks you to name the owner of every schedule, which I like more than any of the technical advice.

All of that applies to agent hosts. Two things are missing, and both come from the fact that the job is an agent.

First, an agent reads the date. A prompt that says “summarize yesterday” is resolved by the model against whatever date it can see, and a job that fires at 00:30 UTC fires at 4:30 p.m. the previous afternoon in San Francisco (5:30 p.m. until this morning). Ask that job for yesterday and it will hand a Pacific reader a summary of the day before yesterday, with total confidence. Second, agents write schedules. Ask one to “remind me at 9 every weekday” and it will pick a timezone for you, or leave the field out, and the cron scheduling guide already notes that a job with no zone runs on the gateway machine's local time. On a cloud box set to UTC, that 9 a.m. reminder arrives at 1 a.m. Pacific.

How Each Schedule Type Behaves When the Clocks Change

The rows below use the next two US transitions: fall-back on November 1, 2026, and spring-forward on March 14, 2027. The OpenClaw schedule kinds are the three documented in the cron workflows guide. The last row is plain system cron, for comparison.

I have not seen the gateway's handling of the repeated hour documented anywhere, which is why the first row says “depending on the scheduler.” Do not take my word or anyone's. Your run log from this morning will show what yours did.

Where Each Option Fits (and Where It Does Not)

UTC is my default, and I hold it loosely. It is the right home for anything whose correctness depends on running exactly once, like the process count that feeds the spawn gate in the host capacity playbook or a nightly backup. It is the wrong home for a morning brief. A brief that arrives at 7 a.m. for eight months and 6 a.m. for four is a brief that gets read half asleep, or not at all.

Local time wins for anything a person reads, and it loses only in that two-hour band in the middle of the night, which is easy to stay out of. Intervals win for pollers and lose the moment someone expects them on the hour. System cron, honestly, handles the transition better than most hand-built schedulers, because Vixie cron has special-cased it for decades. If a job does not need an agent (rotating a log, say), it can stay in crontab and skip the question.

Audit Every Job in Ten Minutes

Print every job with its kind, expression and zone. The // "none" fallback is the column that matters, because a missing zone means the job follows whatever the machine is set to:

jq -r '.jobs[] | [(.name // .label),
  .schedule.kind,
  (.schedule.expr // .schedule.everyMs // .schedule.at // "-" | tostring),
  (.schedule.tz // "none")] | @tsv' ~/.openclaw/cron/jobs.json \
  | column -t -s $'\t'

Then mark each job with one of two words: reader (a person sees the output at a time they care about) or machine (nobody cares when, only that it happened once). Machine jobs move to "tz": "UTC". Reader jobs get the reader's IANA zone, written out, never left blank. Any reader job whose hour field is 1 or 2 moves to 3 or later, or to 0 if it has to be overnight. That last rule costs nothing and removes the whole question.

One warning before you convert. Translating a machine job to UTC means doing the arithmetic for the season you are in. My 4 a.m. Pacific job is 0 11 in summer and 0 12 in winter, and picking either one means it lands an hour off for part of the year. For machine work that is fine. That is the deal.

If you are setting up a new host instead of auditing an old one, the OpenClaw Starter Kit ships with an annotated config, and the first thing worth annotating in it is the zone on every schedule.

Tell the Agent Which Day It Is

Fixing the schedule does not fix the prompt. A job that runs at 06:00 in Los Angeles but reasons about “today” from a UTC timestamp in its tool output will still get the date wrong in the evening. Put the zone in the job's message, every time:

"message": "Today means the current date in America/Los_Angeles.
Summarize yesterday (00:00 to 23:59 Pacific) from memory/daily/.
Write times as Pacific with the offset, e.g. 09:15 -08:00."

Then write a scheduling rule into the files the agent reads at session start, so the next job it creates follows the same convention without you checking:

## Scheduling rules
- Every new cron job sets "tz" explicitly. Never omit it.
- Maintenance and counters: "UTC". Anything a person reads: "America/Los_Angeles".
- No local-time job between 01:00 and 02:59.
- One-shot "at" times end in Z or carry an offset.

Keep it that short. The context budget playbook explains why rules files grow until the end gets cut off, and four lines about clocks should not push something more important out.

The Hour That Happened Twice

At 1:59:59 this morning the clock in San Francisco went back to 1:00:00, and every log line stamped in local time without an offset became ambiguous for exactly sixty minutes.

Check the Morning After

Pull every run from 08:00 to 10:00 UTC today, which covers both passes through 1 a.m. Pacific, and look for any job that appears twice. A doubled cleanup is harmless. A doubled outbound email is not, and the fix is the same one the idempotent jobs playbook describes: give each run a key built from the job name and the local date, and skip the run if that key already exists. A job built that way does not care whether the scheduler fires it once or twice.

Then put March 14, 2027 on a calendar, with a note to check the 10:00 to 11:00 UTC window that morning for jobs that should have run and did not. Missing runs are harder to spot than doubled ones, since there is nothing in the log to look at. The silent failures guide covers the expected-run check that catches them. Europe follows on March 28, so for two weeks London is seven hours ahead again, and anyone with a reader there gets to do this twice.

Related Reading

• How to Build Automated Workflows with OpenClaw Cron Jobs
• The OpenClaw Idempotent Jobs Playbook
• OpenClaw Agent Observability: Detecting Silent Failures
• The OpenClaw Agent Alert Fatigue Playbook

Frequently Asked Questions

Should OpenClaw cron jobs use UTC or local time?

Use UTC for jobs that must run exactly once a day and where the local hour does not matter, such as a nightly backup or a memory sync. Use the reader's IANA zone, for example America/Los_Angeles, for anything a person reads at a fixed time, and keep those jobs out of the 1:00 to 2:59 a.m. window.

What timezone does an OpenClaw cron job use if I leave tz out?

It runs on the gateway machine's local timezone. On a cloud server set to UTC, a job meant for 9 a.m. Pacific will fire at 9 a.m. UTC instead.

Can a cron job run twice when daylight saving time ends?

Yes. On the fall-back night the hour from 1:00 to 1:59 a.m. happens twice in zones like America/Los_Angeles, and a job scheduled inside it can run once or twice depending on the scheduler. Make the job idempotent, or schedule it outside that hour.

When are the next daylight saving changes?

In the United States, clocks fell back on November 1, 2026 and spring forward on March 14, 2027. In the European Union and the UK, they fell back on October 25, 2026 and spring forward on March 28, 2027.