Subject: Time Injection Bug – 12-Hour Offset in System Context Sent to LLM (AM/PM Conversion Error + Duplicated "UTC" Suffix) ## Summary The current time injected into the LLM's system context is offset by exactly 12 hours during the PM half of the day (UTC). Additionally, the timezone suffix "UTC" appears duplicated in the injected string. This causes the AI assistant to operate with an incorrect notion of the current time, which can affect any time-sensitive responses (date reasoning, "today/tomorrow" references, scheduling, tool calls with time parameters, etc.). ## Severity Medium – Does not break functionality, but silently corrupts time-aware responses for ~50% of the day for all users. Particularly problematic because answers remain plausible-sounding while being factually wrong. ## Environment Platform: You.com web chat OS: Windows (10/11) Browser: Brave 1.90.122 Model used when reproduced: Claude (as served via You.com ) Date of observation: 2026-06-13 ## Steps to Reproduce Open a new chat session on You.com at any time during the PM half of the UTC day (i.e. 12:00–23:59 UTC). Verify the actual UTC time in the browser console: new Date().toISOString() Ask the assistant what time it currently believes it is. Compare the assistant's reported time against the browser's UTC value. ## Actual Result Browser console output: 2026-06-13T13:43:20.551Z (= 13:43 UTC) Time string injected into the LLM context (verbatim): "Saturday, June 13, 2026 01:43 UTCUTC" The assistant therefore believes it is 01:43 UTC instead of 13:43 UTC. Two distinct issues are visible in the injected string: (a) Hour value is off by 12 (13:43 → 01:43) — classic AM/PM conversion bug. (b) The literal token "UTC" is duplicated ("UTCUTC"). ## Expected Result The injected time string should contain the correct UTC hour in 24-hour format and a single "UTC" suffix, e.g.: "Saturday, June 13, 2026 13:43 UTC" ## Likely Root Cause (hypothesis) The duplicated "UTC" suggests two code paths concatenating the timezone label onto an already-formatted string. The 12-hour offset strongly suggests the time is being formatted with a 12-hour format specifier without preserving the AM/PM marker. Common culprits: - Python: strftime("%I:%M") used instead of strftime("%H:%M") - Java/ICU: pattern "hh:mm" used instead of "HH:mm" - .NET: "hh:mm" used instead of "HH:mm" - JS Intl: hour12: true without explicit dayPeriod handling The bug only manifests in the PM half of the UTC day, which is consistent with this class of error (AM hours render identically in 12h and 24h format). ## Impact All time-sensitive AI responses are silently wrong for half of every day. Affects scheduling, "what day is today" reasoning, recency judgments, and any backend tool calls that consume the injected timestamp. Users are unlikely to notice unless they explicitly ask the assistant for the current time, making this a high-trust-erosion bug once discovered. ## Suggested Fix Audit the time formatting code path that produces the system-context timestamp; switch any 12-hour format specifiers to 24-hour equivalents. Remove the duplicated "UTC" suffix — ensure the timezone label is appended exactly once. Add a unit/integration test that asserts the injected time string matches a 24-hour ISO-like pattern (regex such as ^[A-Z][a-z]+, [A-Z][a-z]+ \d{1,2}, \d{4} ([01]\d|2[0-3]):[0-5]\d UTC$ ). Consider switching to ISO 8601 format end-to-end (e.g. "2026-06-13T13:43Z") to eliminate ambiguity entirely. ## Additional Notes The bug was identified by cross-checking the assistant's reported time against the browser's new Date().toISOString() output, which returned the correct UTC value. This confirms the client and the user's system clock are correct; the defect is server-side in the time-injection layer that builds the LLM system prompt. Happy to provide further session logs or reproduce on request.
