Problem
The buildTimeSection function in the system prompt only outputs:
## Current Date & Time
Time zone: America/New_York
This means agents don't have a reliable date anchor in their system context. They have to run date or parse the inbound message metadata timestamp to know what day it is. This leads to date hallucination bugs — for example, confidently mapping March 1 as Saturday when it's actually Sunday, and shifting an entire calendar view by one day.
Proposed Fix
buildTimeSection should resolve the current date/time using the user's timezone and include it:
## Current Date & Time
Friday, February 27, 2026 11:43 AM EST
Time zone: America/New_York
This is a one-line change:
function buildTimeSection(params) {
if (!params.userTimezone) return [];
const now = new Date().toLocaleString('en-US', {
timeZone: params.userTimezone,
weekday: 'long',
year: 'numeric',
month: 'long',
day: 'numeric',
hour: 'numeric',
minute: '2-digit',
timeZoneName: 'short'
});
return [
'## Current Date & Time',
now,
`Time zone: ${params.userTimezone}`,
''
];
}
Why It Matters
- Agents currently have to run
date as a tool call just to know what day it is
- Calendar/scheduling tasks are error-prone without a date anchor
- The inbound message metadata has a timestamp, but it's buried in untrusted context blocks
- Having it in the system prompt makes it authoritative and impossible to miss
Workaround
Using the timestamp field from inbound message metadata (server-generated, authoritative) as a date anchor. But this is fragile and requires the agent to know to look for it.
Problem
The
buildTimeSectionfunction in the system prompt only outputs:This means agents don't have a reliable date anchor in their system context. They have to run
dateor parse the inbound message metadata timestamp to know what day it is. This leads to date hallucination bugs — for example, confidently mapping March 1 as Saturday when it's actually Sunday, and shifting an entire calendar view by one day.Proposed Fix
buildTimeSectionshould resolve the current date/time using the user's timezone and include it:This is a one-line change:
Why It Matters
dateas a tool call just to know what day it isWorkaround
Using the
timestampfield from inbound message metadata (server-generated, authoritative) as a date anchor. But this is fragile and requires the agent to know to look for it.