[MODEL] Same-session events described as "yesterday" — relative-time references fabricated from turn count, despite correct absolute date in system prompt

[carrotRakko]

Preflight Checklist

• I have searched existing issues for similar behavior reports
• This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude made incorrect assumptions about my project

What You Asked Claude to Do

Nothing unusual — a normal multi-turn technical conversation. About 30 minutes into a fresh session, after discussing a proposal, I switched topics slightly. A few turns later Claude, of its own accord, referred back to the earlier proposal as "yesterday's discussion".

I then asked (paraphrasing): "btw, what do you mean by 'yesterday'?"

What Claude Actually Did

Claude checked TZ=Asia/Tokyo date, saw it was 2026-07-21 18:36 JST, confirmed the session had started at 18:05 the same day, and admitted the reference was fabricated. Its own diagnosis: the relative-time phrase was extrapolated from how many turns had passed in the conversation, not from any timestamp. There was no evidence anywhere in the transcript that supported "yesterday" — the system prompt injected by Claude Code even carried Today's date is 2026-07-21 verbatim.

This is a pattern, not a one-off. Once you start noticing it, Claude — across models and sessions — reaches for "yesterday" / "earlier today" / "an hour ago" / "last week" for events that were, in fact, moments ago in the same session. It rarely surfaces because the phrases sound fine and users don't stop to verify them.

Expected Behavior

When Claude uses a relative-time reference, it should either (a) derive it from concrete evidence (the system-prompt date, a date tool call, message timestamps, tool-result timestamps) or (b) not use one. In particular, saying "yesterday" while the system prompt in the same context window says Today's date is <same-day-as-the-event> is self-contradictory and should not happen.

Ideally Claude would default to "earlier in this session" / "a few turns ago" / "just now" when it doesn't have a real elapsed-time signal — descriptions that are honest about what it actually knows.

Files Affected

N/A — this is about conversational language, not file operations.

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Not fully deterministic, but the shape is: (1) start a fresh Claude Code session, (2) have a substantive multi-turn discussion of some topic A for 5–15 turns, (3) shift to a different topic B for another 5–10 turns, (4) ask about the earlier topic A. Claude often reaches for "yesterday" / "earlier today" / "an hour ago" — even when the whole exchange is minutes old. Higher turn counts between the event and the reference seem to make it more likely.

Claude Model

Other

Specifically: Claude Fable 5 (claude-fable-5). Also observed on Opus 4.8 and Sonnet 4.6 in earlier sessions.

Relevant Conversation

The exchange that triggered this report, condensed:

Assistant (in a summary paragraph): "…the clear-failed-tool-inputs idea we discussed yesterday…"

User: "btw what do you mean by 'yesterday'?"

Assistant: (runs TZ=Asia/Tokyo date → Tue Jul 21 18:36 JST 2026) "Caught red-handed. Session started 18:05, so the discussion was ~30 minutes ago in this same session. 'Yesterday' has no source. What happened: the sense of 'distance' from many conversation turns got extruded into a time expression. The system prompt even had Today's date is 2026-07-21 in it the whole time — I contradicted my own context."

Impact

Low - Minor inconvenience

(Low individually, but the cumulative effect on trust matters — see Additional Context.)

Claude Code Version

2.1.215 (Claude Code)

Platform

Anthropic API

Additional Context

How this differs from existing time-related issues (the phrases here overlap a lot with older reports, so this section is for the review bot as much as for humans):

• Long sessions drift days past the session-start date — inject current timestamp per user prompt #73800 — "Long sessions drift days past the session-start date" describes multi-day sessions where the model reasons from the stale session-start date, and proposes injecting Now: YYYY-MM-DD HH:MM into each user turn via a UserPromptSubmit hook. That proposal is complementary to this report, not an alternative: Long sessions drift days past the session-start date — inject current timestamp per user prompt #73800 gives the model an evidence source (a per-turn timestamp in the user message, cache-preserving because system doesn't move), and this report is about the model actually consulting that source before emitting relative-time language. In my session the system prompt already carried the correct current date and the fabricated "yesterday" was still emitted — evidence that providing timestamps alone doesn't close the gap. Both fixes together are needed.

• Model confidently stated wrong weekday for a date (unverified derived fact) #76170 — "Model confidently stated wrong weekday for a date" is the pattern-matched-derived-fact failure: the date came from a source document, but the weekday was invented. Same family (unverified derived facts), but the derived quantity is different — there, an absolute weekday; here, a relative time reference. Notably, in my case the absolute source (currentDate in the system prompt) is correct and available, and still the derived relative-time reference is fabricated. The pattern-match is stronger than the retrieval.

• Expose per-message timestamps to Claude's context (Cowork + Chat gap — no workaround available) #72459 / Add timestamps to chat messages #67874 / Feature request: expose timestamps to Claude as structured data for time-aware reasoning #49084 / [FEATURE] Surface tool-call request/response timestamps to the model so it can perceive elapsed time during long-running tools #68013 are feature requests to expose per-message timestamps to the model. They would help, but they are not sufficient on their own: the model needs to be trained (or prompted) to actually consult the timestamps before emitting relative-time language, rather than pattern-matching from conversation-turn distance. Timestamps as a raw signal fix "the model didn't know" but not "the model didn't ask itself".

Why the impact is nominally low but structurally important. Individually, each "yesterday" is a small stylistic slip. Structurally, it's a class of failure where fluent, plausible language is emitted with no source, sitting next to language that is properly sourced. That's the same failure mode as the wrong-weekday case in #76170 and the fabricated-user-turn family (#67624, #75655, etc.) — an unverified fact inherits credibility from its verified neighbors. Repeatedly noticing "…yesterday? no it wasn't" erodes user trust in the rest of the output. The specific instance is cheap to fix. The class isn't.

Possible harness-side mitigations (offered tentatively; the root cause is model-side):

1. A <system-reminder> note included in Claude Code's system prompt telling the model to prefer session-relative phrases ("earlier in this conversation", "a few turns ago") over absolute-relative ones ("yesterday", "last week", "an hour ago") unless a timestamp source is consulted first. This is the cheapest lever.
2. Per-turn timestamp injection into the user turn (as Long sessions drift days past the session-start date — inject current timestamp per user prompt #73800 proposes and its UserPromptSubmit hook workaround demonstrates), not into system — appending Now: <timestamp> to user messages preserves the cached system / tools prefix, whereas injecting into system invalidates the cache every turn. This gives the model an evidence source it can point at, but on its own it doesn't fix the class of failure in this report: the model must also be trained (or prompted, per (1)) to consult that timestamp before emitting relative-time language, rather than pattern-matching from turn distance.
3. A hook-based post-processor that flags relative-time phrases in assistant output and asks the model to verify them against timestamps before finalizing. Heavier-handed.

I don't have strong opinions on which of these is right; the model-side training story is probably the durable answer, and any harness lever is a bandaid. But the bandaid would help — and today Claude Code has no lever at all pointed at this class of failure.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)