Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Feature Request: Expose message timestamps to the model and display them in the UI [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49692•Fetched 2026-04-17 08:34:07
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
iaiieiiaiiei
Participants
github-actions[bot]github-actions[bot]iaiieiiaiiei
Timeline (top)
labeled ×4commented ×1unlabeled ×1

Fix Action

Fix / Workaround

  1. The model cannot see message timestamps. Each message has a timestamp in the infrastructure layer (confirmed via .jsonl transcript), but the model cannot access it. Claude must run date shell commands as a workaround, which is unreliable (sandbox clocks can be wrong, UTC/JST mismatches occur). Users end up correcting Claude about what day it is, repeatedly.

Workarounds I had to build in CLAUDE.md: (1) Step 0: run TZ=Asia/Tokyo date before anything, (2) every response must include current time, (3) never ask the user what day it is, (4) routine prompts include explicit date verification. These should be product defaults.

RAW_BUFFERClick to expand / collapse

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

After a week-long session with Claude Code (April 10-17, 2026), I found that Claude has no awareness of when messages were sent, leading to repeated confusion about dates, timelines, and scheduling. This is a fundamental gap — even LINE and SMS have had per-message timestamps since 2011.

  1. The model cannot see message timestamps. Each message has a timestamp in the infrastructure layer (confirmed via .jsonl transcript), but the model cannot access it. Claude must run date shell commands as a workaround, which is unreliable (sandbox clocks can be wrong, UTC/JST mismatches occur). Users end up correcting Claude about what day it is, repeatedly.

  2. The UI does not display timestamps. Unlike LINE, iMessage, Slack, or virtually any messaging app, Claude Code's chat UI does not show timestamps on messages. Users scrolling through a multi-day conversation cannot tell when each exchange happened.

  3. Routines have timezone issues. A daily-briefing routine running at 05:30 JST reported the date as April 15 when it was actually April 16. The system-injected "Today's date" appears to use UTC, causing a 1-day offset for JST users.

Workarounds I had to build in CLAUDE.md: (1) Step 0: run TZ=Asia/Tokyo date before anything, (2) every response must include current time, (3) never ask the user what day it is, (4) routine prompts include explicit date verification. These should be product defaults.

Environment: Claude Code web/CLI/iOS. Max 20x plan. Asia/Tokyo (UTC+9). 7-day continuous session.

Proposed Solution

A. Expose timestamps to the model (highest impact): Include the timestamp of each message in the context the model sees, e.g. "[2026-04-15 07:10 JST] User: おはよう。" This single change would eliminate most confusion.

B. Display timestamps in the UI: Show timestamps on messages like LINE does — always visible or revealed on hover/swipe, with date separators between days.

C. Fix Routine timezone handling: Inject the correct local date/time (based on user's timezone setting) into Routine sessions, not UTC.

Alternative Solutions

No response

Priority

Critical - Blocking my work

Feature Category

Interactive mode (TUI)

Use Case Example

No response

Additional Context

No response

extent analysis

TL;DR

Expose message timestamps to the model and display them in the UI to resolve date and timezone confusion.

Guidance

  • Expose the timestamp of each message in the context the model sees, including the timezone, to eliminate confusion about dates and timelines.
  • Display timestamps on messages in the UI, similar to other messaging apps, to provide users with a clear understanding of when each message was sent.
  • Fix routine timezone handling by injecting the correct local date and time into routine sessions, based on the user's timezone setting.
  • Consider implementing a default timezone setting, such as using the user's local timezone, to avoid UTC/JST mismatches.

Example

No code snippet is provided as the issue does not contain specific code references.

Notes

The proposed solution focuses on exposing timestamps to the model and displaying them in the UI, which should address the majority of the confusion. However, additional considerations, such as handling timezone settings and ensuring consistency across different platforms (web, CLI, iOS), may be necessary.

Recommendation

Apply workaround: Implement the proposed solution (A, B, and C) to expose timestamps to the model, display them in the UI, and fix routine timezone handling, as this addresses the critical issues blocking the user's work.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#configuration error#environment variable#network issue#logging issue#authentication issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING