[FEATURE] Date/Time Injection into prompts

Upon further reflection, this is not something the main model will just pick up on. It would probably require farming out the steam of timestamps to a light/fast model for it to select from a range of behavior mods for the workflow context.

Not as trivial as originally thought.

+1 on this. We run a persistent agent that manages calendars and schedules. Without the current time in system context, the agent consistently misjudges whether calendar events have passed, gives incorrect time-of-day suggestions, and can't properly frame morning vs. evening overviews. We filed #34530 before finding this issue and are closing it as a duplicate.

We're working around it with a hook that injects the timestamp per turn, but native support would be much cleaner.

Adding a concrete example in support of this — the absence of current time in context just bit us in a very mundane way.

At approximately 7:00 AM local time, a user asked Claude Code to close out a session. Claude responded with "Goodnight" as the sign-off. The user was starting their workday, not ending it. Claude had no way to know — the system prompt contains the current date but not the current time, so it pattern-matched "end of task" to "end of day" and picked an evening-appropriate phrase.

This is a new angle on the issue that neither of the existing comments covered: sign-off and greeting appropriateness, which is a trivial-sounding but surprisingly load-bearing part of how trustworthy an AI collaborator feels. A user who hears Claude say "goodnight" at 7 AM starts quietly wondering what else Claude is guessing about. It is a small paper cut that undermines confidence in basic situational awareness.

The cheap version is pure upside: match the existing precedent of injecting the date, just include the time alongside it. The expensive interpretive version can be scoped separately if it is worth pursuing.

A concrete proposed change: wherever Today's date is YYYY-MM-DD is currently added, extend it to something like:

Today is Thursday, April 9, 2026.
Current local time: 7:05 AM (America/Denver).

Updated on every user message, not just session start. Two lines, zero model change, fixes a broad class of temporal reasoning failures.

+1 on the original request.

Timestamping would also allow the models to be aware of the timeline of saved memories and when which task was done. The models could also detect if a (sub-) process is stuck.

This is also an issue with Claude Chats, and is just as impactful there.

Working around with prompts to check the time on each turn, and prepend to each message, is unreliable. Claude will start to ignore the prompt and fall back on inferring the passage of time based on the chat context.

This is to the extent it will produce incorrect timestamps based on this inference, even when it has been prompted to check using a clock (user_clock_v0 or date command) before doing so.

The ambient date-string update would close the most common case. Adjacent to this is freshness of data already in context: a file the agent Read 30 minutes ago that has since been edited externally; a stock quote pasted in from earlier in the day; a "current Python version" claim that came from training cut off months ago. Even with a fresh date in the prompt, these don't surface as stale.

I built a skill that covers this slice: AsOf. It records file mtime at each Read via PostToolUse, re-stats them in UserPromptSubmit, and emits a verdict block when anything has drifted. The same hook parses the user's prompt for embedded dated content (Q3 2025, log entries with timestamps) and surfaces the gap against today's date. Training-cutoff comparison is included.

The current-date injection in this issue and the in-context staleness check are complementary layers. The first tells the agent what now is; the second tells it which parts of its existing context still hold.

pip install asoftime && asof install. In A/B runs on Opus 4.7 and Sonnet 4.6, the model re-stats the file before answering rather than reasoning from the stale read.

+1 — and I'd push on the timezone dimension as a concrete reason this should be built in and on by default.

My agent's shell is sandboxed to UTC, and the only temporal signal in context is the current date — no time, no timezone. So any time the agent writes a timestamp (activity logs, a journal entry, "has this calendar event passed yet?") it's either UTC or a guess. Every workaround leaks: deriving the zone from git commit offsets or a connected calendar only gives a static home zone that's wrong the moment you travel, and TZ=… date is unreliable cross-platform (see #50753).

The proposal here fixes it at the source. A full localized datetime string per prompt (e.g. Tue Mar 10 10:16:46 PDT 2026) gives the model the user's actual current local time — correct even when traveling, because it reflects the machine clock at send time. And that same 29-char string already covers the inter-prompt-gap and session-duration awareness from the original post.

Concretely, strong +1 on: (a) include time and timezone, not just date; (b) inject per-prompt, not just at session start; (c) on by default. Closely related: #34530, #32988, #4514.

Big +1 on the timezone part. Reading the machine clock at send time is the only thing that's actually right when you travel — the git-offset and calendar-home-zone tricks all break the second you cross a timezone.

One thing worth separating though: "what time is it now" and "is the stuff already in my agent's context still true" are two different problems. This thread's the first, which is the easy one. The second bites differently — a file my agent Read half an hour ago that's been edited since, a quote that's been sitting in its context since this morning, a "latest version is X" that's really just the training cutoff talking. A fresh timestamp up top doesn't catch any of that. So I'd ship the clock part on its own and not hold it up for the harder freshness stuff.

(If anyone wants both today, I put together AsOf — per-prompt local time + tz plus the staleness flags. But the basic clock thing should really just be built in.)

Just discovered /remote-control injects a <system-reminder> of the time in UTC- except this is inconsistent with desktop messaging, and also, I'm Australian, so the date is just straight up wrong for a large portion of the day and contradicts the date that's already inside the system prompt.

I also use automated logging for some projects keyed to my timezone. I'd like the option to turn off this automated system reminder attached to /remote-control, or at the very least an option to pin it to my actual timezone.

+1 on this. it bit me exactly the way OP describes.

i start a session on day 1, leave it open, come back day 2. claude still thinks it's day 1 until i correct it. the model has no clock. the only date it ever sees is the one injected at session start, and nothing refreshes it. a session that crosses midnight is navigating on yesterday's fix.

i run the fix as a UserPromptSubmit hook, but i made it gap-aware instead of every-prompt. two reasons:

1. a timestamp that changes on every prompt changes your context every turn, which fights prompt caching. a stamp that only fires when it matters is nearly free. i suspect this is also why it isn't built in yet.
2. there's research showing models mostly ignore quiet timestamps even when they have them (arXiv 2510.23853, under 4% citation rate). so when mine fires, it fires loud.

the hook stays silent on normal prompts. it speaks only when the calendar day rolled over or more than 3 hours passed since the last prompt:

#!/bin/bash
# clock-pulse: gap-aware time grounding for long sessions.
GAP_HOURS=3

input=$(cat)
sid=$(printf '%s' "$input" | python3 -c 'import json,sys; v=json.load(sys.stdin).get("session_id","nosid"); print(v if v else "nosid")' 2>/dev/null)
[ -n "$sid" ] || sid=nosid

state_dir="$HOME/.claude/hooks/state"
mkdir -p "$state_dir" 2>/dev/null || exit 0
sid_hash=$(printf '%s' "$sid" | shasum -a 256 | awk '{print $1}')
state="$state_dir/clock-pulse-$sid_hash"
find "$state_dir" -name 'clock-pulse-*' -mtime +7 -delete 2>/dev/null

now_epoch=$(date +%s)
today=$(date '+%Y-%m-%d')

last_epoch=""; last_day=""
if [ -f "$state" ]; then
  IFS=' ' read -r last_epoch last_day < "$state"
fi
printf '%s %s\n' "$now_epoch" "$today" > "$state" 2>/dev/null || exit 0

# first prompt of a session (or corrupt state): stay silent --
# session start already carries the date
case "$last_epoch" in
  ''|*[!0-9]*) exit 0 ;;
esac

gap_sec=$(( now_epoch - last_epoch ))
if [ "$last_day" != "$today" ] || [ "$gap_sec" -gt $(( GAP_HOURS * 3600 )) ]; then
  hrs=$(( gap_sec / 3600 )); mins=$(( (gap_sec % 3600) / 60 ))
  msg="TIME CHECK: it is now $(date '+%Y-%m-%d %H:%M %Z'). ${hrs}h ${mins}m have passed since the previous prompt."
  if [ "$last_day" != "$today" ]; then
    msg="$msg The calendar day has rolled over ($last_day -> $today). Any dates assumed from earlier context are stale."
  fi
  printf '%s\n' "$msg"
fi

if this ships natively, i'd vote for the gap-aware behavior over per-prompt injection, with the threshold as the config flag. per-prompt is the obvious version but it pays a cache tax on every turn to solve a problem that only shows up a few times a day.