You know, you’re right. I was thinking about Gemini, which I’m much more familiar with, when I made that statement. I just logged on to Claude and prompted Haiku 4.5 “What time is it (PST)?” and it replied “3:22 PM,” also claiming I’m in Longview, WA. The actual time is 9:29 AM, and I’m in Portland, OR, about 50 miles away.
Sonnet 4.6 and Opus 4.7 also deny having access to the time. Like Haiku 4.5, they claim I’m in Longview, WA. When I repeatedly, explicitly prompt Opus 4.7 to search the web to look up the time, it came back with a claim that it’s 9:25 PM PST, so again, about 12 hours off.
Gemini flash-lite gets the time and location right. During the prompt response construction, it flags “searching the web...” Since I’ve never had this issue with Gemini, I just assumed it was a solved problem for leading models generally. Sorry for displaying maximum overconfidence!
I prompted Opus 4.7, asking “if you were going to look up an accurate time, how would you do it?” It replied as follows:
You’re right to push back — that timestamp was from when the page was cached/fetched, not truly “now.” Web fetches don’t give me a live clock; they give me a snapshot of a page at fetch time, and there’s latency in between.
Honestly, there isn’t a great way for me to get a truly accurate current time through the tools I have:
web_fetch returns page content but with unknown lag, and many time sites render the clock via JavaScript that I don’t execute — so I either get a stale server-side timestamp or a placeholder.
web_search returns snippets and indexed content, which is even more stale.
I don’t have a system clock tool, a date command with network access, or an NTP query available in this conversation.
The closest I could get would be fetching something like worldtimeapi.org/api/timezone/America/Los_Angeles (a JSON API that returns a server-generated timestamp at request time), which would be accurate to within a second or two of when the fetch executed. But even then, by the time you read my reply, that timestamp is already seconds to minutes old.
I then prompted Gemini Pro 3.1, supplying Opus’s response and asking how its capacity to retrieve the current time differs. It replied:
Claude’s explanation is actually a great breakdown of the challenges an AI faces if it has to actively “look up” the time using standard web-browsing tools. If an AI has to scrape a webpage or ping an external API, it runs into latency, JavaScript rendering issues, and caching.
My capacity is different because I don’t have to go looking for the time—it is given to me automatically.
Here is how my time awareness works:
Context Injection: I don’t use a search tool or an API to find the time. Instead, the system hosting me injects a live timestamp (along with your current location) directly into the hidden system instructions of every single prompt you send.
Zero-Latency Retrieval: Because the time is bundled into your message before I even start “thinking,” there is no web-fetch lag or caching to worry about.
The “Snapshot” Reality: Like Claude mentioned, there is still a slight reality gap. The time I see is the exact second the system processed your message (in this case, 9:37:54 AM PDT). By the time I finish generating my response and you read it, a few seconds will have passed.
So, rather than giving me a tool to check the clock, my system just puts a clock right on the desk in front of me every time you speak.
Huh, I just assumed Gemini was getting timestamps and Claude isn’t. That’s kind of funny that it uses the web search tool to get the time. Claude on the web has a user_time_v0 tool and it seems to work:
It’s 12:27 PM on Friday, May 22, 2026, in your timezone (PDT, UTC-7). Just past noon — lunchtime in Redmond.
(The city is correct too)
Claude Code said it doesn’t have this tool but would just run the date command if it needed the time. Also, it only knows the time zone because of my CLAUDE.md.
Yeah, I’m not sure if either model’s account can be trusted. Gemini displays the ‘searching the web’ banner when I ask, yet claims to get the time from a prompt-injected timestamp. Claude claims not to have access to a tool to retrieve any up to date time or location data, yet it sounds like you’re able to get that via the user_time_v0 tool. Did you have to somehow prompt Claude to use that tool?
I re-opened the conversation from earlier today where it mentioned the tool and just prompted it to lookup the time using the tool. The “Check current time” tool call summary suggests that this is a real tool, and it did this mid-conversation and got the exact correct time and city:
I’m not sure if it matters but this was on the Android app.
Huh, I just tried prompting it “can you look up the current time using the user_time_v0 tool?”, but it said it has no access to such a tool. I’m using the browser chat interface on my laptop. Just got out my phone (iPhone) and tried it, and it got the time correct. So yeah, I’m thinking it’s a phone vs. computer browser discrepancy in available tools.
Huh, Claude says it only gets the time in the system prompt and has to use tools if it wants to look it up mid-conversation.
You know, you’re right. I was thinking about Gemini, which I’m much more familiar with, when I made that statement. I just logged on to Claude and prompted Haiku 4.5 “What time is it (PST)?” and it replied “3:22 PM,” also claiming I’m in Longview, WA. The actual time is 9:29 AM, and I’m in Portland, OR, about 50 miles away.
Sonnet 4.6 and Opus 4.7 also deny having access to the time. Like Haiku 4.5, they claim I’m in Longview, WA. When I repeatedly, explicitly prompt Opus 4.7 to search the web to look up the time, it came back with a claim that it’s 9:25 PM PST, so again, about 12 hours off.
Gemini flash-lite gets the time and location right. During the prompt response construction, it flags “searching the web...” Since I’ve never had this issue with Gemini, I just assumed it was a solved problem for leading models generally. Sorry for displaying maximum overconfidence!
I prompted Opus 4.7, asking “if you were going to look up an accurate time, how would you do it?” It replied as follows:
I then prompted Gemini Pro 3.1, supplying Opus’s response and asking how its capacity to retrieve the current time differs. It replied:
Huh, I just assumed Gemini was getting timestamps and Claude isn’t. That’s kind of funny that it uses the web search tool to get the time. Claude on the web has a
user_time_v0tool and it seems to work:(The city is correct too)
Claude Code said it doesn’t have this tool but would just run the
datecommand if it needed the time. Also, it only knows the time zone because of my CLAUDE.md.Yeah, I’m not sure if either model’s account can be trusted. Gemini displays the ‘searching the web’ banner when I ask, yet claims to get the time from a prompt-injected timestamp. Claude claims not to have access to a tool to retrieve any up to date time or location data, yet it sounds like you’re able to get that via the user_time_v0 tool. Did you have to somehow prompt Claude to use that tool?
I re-opened the conversation from earlier today where it mentioned the tool and just prompted it to lookup the time using the tool. The “Check current time” tool call summary suggests that this is a real tool, and it did this mid-conversation and got the exact correct time and city:
I’m not sure if it matters but this was on the Android app.
(The random Spanish is from my system prompt)
Huh, I just tried prompting it “can you look up the current time using the user_time_v0 tool?”, but it said it has no access to such a tool. I’m using the browser chat interface on my laptop. Just got out my phone (iPhone) and tried it, and it got the time correct. So yeah, I’m thinking it’s a phone vs. computer browser discrepancy in available tools.