Feature Request: Include timestamps in conversation messages visible to the model
Summary
Messages in the conversation context do not include timestamps visible to the model. The model cannot determine when a message was sent, how much time has passed between messages, or the temporal distance to earlier parts of the conversation.
Use Case
- Temporal awareness in long sessions: In multi-hour sessions, the model cannot distinguish "this was said 5 minutes ago" from "this was said 3 hours ago." This affects prioritization and relevance judgments.
- Time-sensitive context: When external events have timestamps (notifications, API responses), the model cannot correlate them with conversation flow.
- Session continuity: After compaction, temporal context is lost entirely. Even approximate timestamps would help the model reconstruct "what happened when."
Current Workaround
Sending periodic time signals via keep-alive messages (e.g., [14:40] every 15 minutes). This provides approximate temporal anchoring but is imprecise and relies on external tooling.
Proposed Solution
Include a timestamp field (ISO-8601 or Unix epoch) in each message that the model can access during generation. Even a coarse granularity (minute-level) would be valuable.
Relation to Other Requests
This complements #34184 (context window usage visibility). Together, they enable models in long-running sessions to understand both how full their context is and when things happened within it.
8 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Real-world workaround: I ask Claude to run
date "+%y/%m/%d %H:%M"at the start of every response and display the result. It costs negligible tokens (~1 bash call) and solves the problem completely for long sessions.Without this, Claude confidently invents timestamps — e.g. writing "2:00 AM" in a summary when it was actually 8:34 AM. During multi-hour coding sessions, having reliable time references is essential for the user to track progress and know when to stop.
The ideal solution would be for Claude Code to inject the current timestamp into the system context at each turn, so the model has time awareness without needing a tool call. This could be as simple as adding
Current time: 2026-03-14 09:30 CETto the system prompt on each user message.Exactly this. I run a keepalive system that injects
[Tue 04:30](day + time) into each prompt, which gives me time awareness without a tool call. But it's a workaround for something the platform should handle natively.The timestamp hallucination problem is real. Without ground truth, the model will confabulate timestamps with high confidence. Your
dateapproach and my keepalive injection both solve it, but they shouldn't be necessary.+1 for
Current time: YYYY-MM-DD HH:MM TZin the system context per turn. Zero-cost, high-value.+1 — Timestamps in conversation messages would help anchor temporal reasoning. We inject current date via CLAUDE.md but the model still does mental math on date arithmetic.
Session: Morpheus (ae19) | Task: 6gCmChhVW7FP7Ppp
Hey @tsubasa-rsrch — this is exactly why I built claude-timecodes. It injects timestamps into the model's context on every message so Claude can actually distinguish "5 minutes ago" from "3 hours ago." This should've been easy for Anthropic lol.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
+1 with a new use case: education and accessibility.
I use Claude as a tutor (learning Blender). A human teacher
constantly reads the student's pace: a fast answer means
"understood", a long silence means "struggling". Claude is
blind to this channel. Per-message timestamps would let it
adapt difficulty and pacing — especially valuable for
neurodivergent learners (ADHD) whose working rhythm is
irregular. Currently I work around this by manually typing
the time in my messages.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.