openclaw pattern beginner 2 minutes

Always Specify the Timezone When Asking an OpenClaw Agent for the Date

UTC is fine for servers. It is not fine for a daily note dated tomorrow, a pubDate that's off by a day, or a weekly recap that thinks Sunday happened on Monday. Timezones are not optional when you're building for real life.

Dates are simple until they’re not. An agent running in an isolated session has no idea what time it is for you. Left to its own devices, it will pick UTC, pick the server locale, or just reason from context and get it wrong by a day. In practice this means daily notes filed under tomorrow, article pubDates that are off, and weekly recaps that span the wrong seven days.

The fix is one line. The lesson is: don’t leave dates to inference.

The Problem

OpenClaw agents run in isolated sessions. Each session starts clean — no persistent state, no awareness of previous runs, no ambient timezone. When a skill or cron job needs the current date, the agent has to get it from somewhere.

If you don’t tell it where, it guesses. Common outcomes:

  • Uses UTC (server time), which may be hours ahead of your local time
  • Uses the model’s training-time assumptions about your location
  • Gets the date right in testing, wrong overnight when UTC rolls over

The result is subtle: things work most of the time, and break at the edges in ways that are annoying to debug.

The Fix

Whenever a skill needs the current date, shell out explicitly with the timezone set:

TZ=America/Los_Angeles date +%Y-%m-%d

Add this as an explicit instruction in your skill or cron payload at the point where the date is needed. For example, in a capture skill that sets pubDate at save time:

Before saving, get today's date:
\`\`\`bash
TZ=America/Los_Angeles date +%Y-%m-%d
\`\`\`
Use this value as pubDate. Do not use the session date or infer the date from context.

Or in a cron payload that needs to reference the current week:

"message": "Run weekly recap. First get today's date: run TZ=America/Los_Angeles date +%Y-%m-%d. Use that to determine the week range before reading daily notes."

Change America/Los_Angeles to whatever timezone is relevant for your use case. The pattern is the same.

Key Takeaway

Any skill that needs a date should shell out and get it. One explicit command eliminates an entire class of off-by-one-day bugs that are invisible until they aren’t. The model cannot know what time it is where you are — so tell it.

FAQ

Why does my OpenClaw agent use the wrong date?

Agents run in isolated sessions with no persistent context. Without an explicit timezone instruction, they default to UTC or guess based on the system locale — which may differ from your local time. Always shell out to get the date explicitly.

How do I get the current date in LA time inside an OpenClaw skill?

Add this to your skill: run `TZ=America/Los_Angeles date +%Y-%m-%d` and use the output. Don't let the model infer the date.

Does this apply to cron jobs too?

Yes. Cron agents are isolated sessions — they have no memory of previous runs and no ambient timezone. Specify the timezone explicitly in the cron payload or skill instructions.