Hosted web_search tool injects a UTC "current date" into the model context, overriding developer-provided local date (off-by-one for non-UTC users)

API Bugs
1

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.

1 Like