Sascha Timpel
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
  1. 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).
  1. Verify the actual UTC time in the browser console:
new Date().toISOString()
  1. Ask the assistant what time it currently believes it is.
  2. 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
  1. Audit the time formatting code path that produces the system-context
timestamp; switch any 12-hour format specifiers to 24-hour equivalents.
  1. Remove the duplicated "UTC" suffix — ensure the timezone label is
appended exactly once.
  1. 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$ ).
  1. 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.