openclaw - 💡(How to fix) Fix Agent lacks reliable wall-clock time source and appears to rely on uptime only

Summary

OpenClaw/Cleo appears to lack an explicit reliable wall-clock time source exposed to the agent. The system seems to provide uptime/process uptime, but uptime is not a substitute for current date/time.

This creates a serious architectural limitation for any agent behavior involving scheduling, heartbeat events, memory chronology, deadlines, logs, reminders, or reasoning about today, tomorrow, yesterday, and recency.

Problem

Uptime only indicates how long the system or process has been running. It does not provide:

• current date
• current local time
• UTC timestamp
• timezone
• weekday/calendar context
• DST awareness
• deadline awareness
• reliable heartbeat timestamps
• reliable memory chronology
• reliable scheduling context

If the agent only receives uptime, it may incorrectly infer temporal facts or fail to reason safely about time-sensitive tasks.

Why this matters

Agents need a clear distinction between:

Wall-clock time

Used for: current date/time, user-facing temporal reasoning, deadlines, reminders, scheduling, heartbeat timestamps, memory timestamps, logs, recency checks.

Monotonic time / uptime

Used for: elapsed duration, process health, timeouts, retries, performance measurements.

Uptime must never be used as a proxy for wall-clock time.

Proposed solution

OpenClaw should expose an explicit time authority to the agent, either as a tool or as runtime context.

Suggested tool name: system_time_now / get_current_time / clock.now

Suggested response shape:

Required behavior

The agent should follow this policy:

• The agent has no intrinsic internal clock
• For any time-sensitive reasoning, scheduling, recency check, heartbeat, deadline, reminder, or calendar-related task, the agent must use the runtime time tool or an explicit timestamp provided by OpenClaw
• System uptime is not wall-clock time
• If reliable wall-clock time is unavailable, the agent must explicitly report that time context is unavailable rather than guessing

Acceptance criteria

• Asking what time is it? calls the clock/time tool
• Heartbeat events include UTC and local timestamps
• Memory writes include created_at and/or observed_at
• Logs include started_at and completed_at where applicable
• Today/tomorrow/yesterday are resolved from wall-clock date, not uptime
• Uptime is only used for elapsed duration and process health
• If wall-clock time is unavailable or unsynchronized, the agent reports uncertainty

Severity

Medium-high / architectural. This affects correctness, safety, and reliability of autonomous or semi-autonomous agent behavior.