[FEATURE] Date/Time Injection into prompts

Preflight Checklist

I have searched existing requests and this feature hasn't been requested yet
This is a single feature request (not multiple features)

Problem Statement

Claude Code has basically no temporal awareness beyond the current date. It can't detect prompts that are coming in quick series vs hours apart, nor can it tell if a session has been running continuously for a very long time. Sonnet and Opus are both completely smart enough to make use of that information as context for response framing or inquiries as to next actions.

Proposed Solution

A standard date/time string (e.g. Tue Mar 10 10:16:46 PDT 2026) is 29 characters. Adding it to the context for each prompt would be trivial. A config flag for the behavior seems like a natural.

Alternative Solutions

I'm doing this with a hook, which isn't hard to set up, but this seems like something that should be built in and on by default. Injecting via a hook probably incurs more overhead than would be needed if it was built in.
{"hookSpecificOutput": {"additionalContext": "currentTime": "Tue Mar 10 10:50:35 PDT 2026"}}

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

A

work in a 3-hour session, prompting consistently over time
2 hour gap for meetings
return to session - Claude Code recognizes the gap, can infer that user short term memory is flushed and make fewer assumptions about the warmth of their wetware cache

B

work in a 12-hour continuous session
Claude Code may recognize signs of fatigue in decision making or responses, maybe be more cautious on destructive changes

C

working sporadically in multi-tasking mode for 6 hours
Claude Code may recognize distraction and prompt for certainty/clarity

Additional Context

This is less a user workflow feature and more a general tool quality and capability feature. The extent of current model intelligence makes it hard to predict exactly how much mileage this will provide, but as models continue to get smarter the behavior improvement around temporal awareness will grow as well.

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 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:

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.
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.

+1 Adding a per-prompt timestamp can't be too expensive -- I would think two tokens at most. If the back end were expecting it as an optional field to a prompt, then I'm sure a format could be used that could reduce it to a single token. For example, if the start time of the session is recorded in the context (likely two tokens) and the prompt timestamp sent as an offset (and yes, calculating that based upon time zone from the UI, rather that be Cluade Code or the web UI), then we should be in the single token territory and the back end should know the timestamp with second-precision.

But it gets annoying when I tell the UI I'm tired and going to sleep. Then the next day I prompt and it repeats "get some rest!" LOL

Some measured data in support of making timestamp injection a default rather than an opt-in hook.

I run Claude (Cowork mode) against a personal knowledge vault, with sessions archived and machine-audited nightly. Because Cowork does not fire UserPromptSubmit hooks (#63360), the model has no per-turn time signal there — only the session-start date. I censused 656 archived sessions (≈3,650 assistant turns) for "stamp-of-now" shapes written by the model (~HH:MM, HH:MM + timezone, or ISO-date + HH:MM) and checked whether a clock command (date) was executed in the same response:

107 of 209 timestamp-writing turns (51.2%) had no same-response clock read — i.e., the model interpolated or invented the time.
The rate is uniform whether or not the clock was read earlier in the session (49.0% vs 51.9%), so this isn't stale-anchor confusion — the model simply doesn't classify "writing a timestamp" as requiring a lookup.
Worst single incident: ten fabricated timestamps written into permanent records in one hour, in a session where the model had just correctly applied the clock rule and written a note about why it matters. Prompt-side rules do not fix this; we've iterated them since July and the failure recurs.
On the CLI, the UserPromptSubmit injection hook fixes the class outright (installed 2026-08-16, verified). The remaining failure surface is exactly the one where hooks don't fire.

Conclusion from the data: time awareness is a harness property, not a model-discipline property. Injecting the timestamp per turn (or at minimum firing hooks in Cowork, #63360) removes the failure class at the root; everything else we've tried only measures it.

Data point for the weekday half of this request. The injected line is Today's date is 2026-10-01 with no day of week, and on 2026-10-01 (a Thursday) Claude Code named a file ...-Wed-... from memory before anything in the turn had run date. The file went into an issue tracker that has no delete, so the wrong weekday is permanent.

#18374 asked for exactly this and was auto-closed for inactivity; #55793 asked for the time and zone and was auto-closed as a duplicate of this one. So +1 for folding the weekday in here along with local time and timezone.

One more point: the only user-side fixes are a UserPromptSubmit hook that injects date '+%A %Y-%m-%d %H:%M %Z', or a rule in CLAUDE.md telling the model never to type the weekday from memory. CLAUDE.md is capped at 150k characters and competes for context on every turn, so spending bytes there to patch a missing clock is a poor trade. The clock belongs in the harness, which already injects the date and knows the machine's timezone. One extra token-cheap field would retire a whole class of errors.

Title: Show a timestamp on each prompt and each response

Feature request:
Please display the date and time at the end of every user prompt and
every Claude reply in the session. The response timestamp is the more
important of the two.

Problem:
I often run several Claude Code sessions in parallel, each working on a
different PR. When I switch between them, I sometimes lose track of
which session is which and accidentally type my reply into the wrong
one, usually an older session I had already finished with.

Why a timestamp solves it:
If each reply shows when it was completed, I can see at a glance when
that session last finished its work. That lets me confirm I am in the
current session, and not an old one, before I send my next message.

Suggested behavior:

A small, unobtrusive timestamp (local time) on the last line of each
message, e.g. "2026-10-13 14:32"
A setting to turn it on or off, and to choose the format

Navigation Menu

Repository navigation

[FEATURE] Date/Time Injection into prompts #32913

Preflight Checklist

Problem Statement

Proposed Solution

Alternative Solutions

Priority

Feature Category

Use Case Example

A

B

C

Additional Context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE] Date/Time Injection into prompts #32913

Description

Preflight Checklist

Problem Statement

Proposed Solution

Alternative Solutions

Priority

Feature Category

Use Case Example

A

B

C

Additional Context

Activity

benn-herrera commented on Mar 11, 2026

adamgfraser commented on Mar 15, 2026

ojhurst commented on Apr 9, 2026

renne commented on May 4, 2026

lukejackson commented on May 4, 2026

amatayomosley-web commented on May 28, 2026

bkowshik commented on Jun 8, 2026

amatayomosley-web commented on Jun 8, 2026

cadaeix commented on Jun 12, 2026

cogpros commented on Jul 16, 2026

daniel-santos commented on Aug 5, 2026

butter418 commented on Aug 27, 2026

UNIVAC-Colonel-Panic commented on Oct 1, 2026

shajahank1 commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions