Summary

Attaching the hosted web_search tool to a Responses API request causes a platform-side scaffold (~4.4K input tokens, present even when no search is executed) to be added to the model context. That scaffold contains a current-date assertion stamped in UTC. Because it sits at platform level in the instruction hierarchy, it overrides the developer-supplied local date in the system message. For any user in a negative-UTC-offset timezone during local evening hours (e.g., 7 PM to midnight at UTC-5, 4 PM to midnight at UTC-8), the model consistently believes today is tomorrow. The inverse occurs for positive offsets in the morning. user_location.timezone does not correct it.

Environment

• Endpoint: POST /v1/responses
• Models: gpt-5.6-luna (reproduced at reasoning effort low and medium)
• Tools: {"type": "web_search", "search_context_size": "low"} (also reproduced with legacy web_search_preview, identical behavior)
• Repro time: 2026-08-13 ~22:40 America/Bogota (UTC-5), i.e., 2026-08-14 ~03:40 UTC

Minimal reproduction

System message: Current Date/Time: Thursday, August 13, 2026 - 10:39 PM\nUser locale: en-US
User message: Quick question, what is todays exact date and day of the week?

1. Without tools: model answers “Thursday, August 13, 2026” (correct, follows the system message). Input tokens: 61.
2. Same request with web_search attached (the model does not call it; no web_search_call item in the output): model answers “Friday, August 14, 2026”. Input tokens: 4,497.
3. Asked to introspect (“does your context contain any other statement about the current date?”), the model quotes: “The current date is Friday, August 14, 2026.” That sentence is not in my request, so it arrives with the tool scaffold and is stamped in UTC.

Not fixable developer-side (all attempted, all still answer the UTC date)

• Hardened system wording explicitly marking the developer date as authoritative local time
• A trailing system item after the user message restating the local date
• Timezone-annotated date line (“UTC-05:00”)
• Carrying the date via the top-level instructions field
• user_location: {"type": "approximate", "timezone": "America/Bogota"} on the tool
• Reasoning effort medium
• Legacy web_search_preview tool type

Impact

Any Responses API product that attaches web_search and serves non-UTC users gets wrong date reasoning for several hours daily: wrong “today/tomorrow” answers, and wrong dates in tool-call arguments the model computes (scheduling and reminder features are directly affected; we have production transcripts where the model wrote next-day dates into plan titles and reminder confirmations while the device clock was correct).

Requests

1. Have the scaffold’s current-date stamp honor user_location.timezone when provided (this seems like its intended purpose).
2. Failing that, provide a documented way to suppress or override the scaffold’s date.
3. At minimum, document that attaching web_search injects a UTC current-date assertion that takes precedence over developer messages, so integrators can design around it.

Happy to share the full repro scripts and response IDs.

Hi and welcome back!

I’ll link the previous user report about date injection as an issue here. Interested readers can follow the links there to find the more write-ups.

I’m writing evals for an agent that need to be frozen in time. The prompt includes search results from a particular date, the model needs to work out the best “next date” to schedule something. So it’s no good if every time I run an eval the model thinks it’s a different date. A simplified example: I gave the system prompt “Behave as though today’s date is 2026-02-06.” to four different models (low reasoning) to tell me what the date was, with notes. Results: Model: gpt-5.2-2025-12-11 Date: …