[BUG] No local time or timezone in context - Claude reasons about time-of-day in UTC and says this evening in the morning

Summary

The system prompt gives Claude a bare calendar date with no time and no timezone, while the
only timestamps otherwise present in its context (session transcript entries) are UTC. The
model therefore has no local-time signal at all, and when it reasons about time of day it
lands on UTC. On a UTC-5 machine this means Claude says "this afternoon" at 7am and "this
evening" before lunch, repeatedly, across sessions.

This is upstream of #64988 (times Claude reports defaulting to UTC) and #81395 (/usage
display timezone). Those are about rendering a time Claude already knows. Here Claude never
knows the local time in the first place, so no amount of correcting the display layer fixes it.

What Claude receives

The injected line is exactly:

Today's date is 2026-08-05.

No hour, no minute, no timezone name, no UTC offset. Meanwhile transcript entries in
~/.claude/projects/<project>/<session>.jsonl are written as:

{"timestamp":"2026-08-05T12:08:42.941Z", ...}

So the one clock reading reachable from context is UTC, unlabelled as "not yours".

Reproduction

1. Set the system timezone to anything with a meaningful UTC offset. Mine is

America/Chicago (CDT, UTC-5); the effect gets worse the further from UTC you are.

1. Start a session in the morning, local time.
2. Ask Claude something that makes it refer to the current time of day, e.g. "summarize what

we did this morning" or just let it narrate ("I'll pick this up this evening").

Observed at 07:10 CDT:

$ date
Wed Aug  5 07:10:17 CDT 2026
$ date -u
Wed Aug  5 12:10:17 UTC 2026

Claude treats it as roughly midday-to-afternoon. Users in UTC+8 through UTC+12 get the
mirror-image failure, where Claude is hours behind them.

Expected

Claude should be able to tell what time it is where the user is. Any of these would do it,
roughly in order of preference:

1. Include local time and IANA zone in the same injected line, e.g.

Today's date is 2026-08-05. Local time is 07:10 (America/Chicago, UTC-05:00).
The binary already resolves the local zone via Intl for other purposes, so the value is
in hand.

1. Failing that, include the UTC offset alongside the date so the model can convert

the UTC transcript timestamps itself.

1. At minimum, label the transcript timestamps as UTC where they surface in context, so the

model stops silently reading them as wall-clock local.

Untested corollary worth checking

If the injected date is itself derived in UTC rather than local time, then for UTC-negative
users the date is also wrong for the last few hours of every day — at 19:30 CDT, UTC has
already rolled over to the next calendar day. I have not confirmed which way this one goes;
the time-of-day problem above reproduces regardless. Note #51110 was the same class of bug in
routines and was fixed there.

Workaround

Same shape as the one in #64988: a CLAUDE.md rule telling Claude to run date before making
any time-of-day statement. It works, but it costs a tool call to learn something that should
have arrived with the prompt, and it only fires when Claude remembers to consult the rule.

Environment

• Claude Code 2.1.220
• Windows 11 Pro 10.0.26200, VS Code extension
• System timezone: America/Chicago (CDT, UTC-5 at time of writing)
• Reproduces independent of model choice