Problem
When answering date-relative questions ("what's due this week?", "when am I free today?"), the model has to reason about dates itself — computing an end-of-week date, mapping today to a schedule's weekday, anchoring "now". It knows the wall-clock date from its own context, but it does not know the account's timezone (e.g. America/Denver).
Observed in live testing against the deployed server (isolated fresh agents answering real prompts):
- Agents inferred "now" from the freshest task
updatedTime stamp because nothing returns the current time.
- Some stated the wrong day of week ("Sunday" when it was Monday).
- "This week" window math risks being off by the account's UTC offset.
Note: relative filters the model delegates to the server (dueDate:'today') already resolve correctly server-side via the account zone. The gap is the reasoning the model does on its own.
Proposed fix (cheap, additive)
Surface an account-context line on responses the model already reads — task-list responses (formatTaskList, used by both list and list_all_uncompleted) and schedule responses (formatScheduleList):
Account timezone: America/Denver | Today: 2026-08-24 (Monday)
The timezone is already resolved (resolveDisplayTimeZone off the cached schedules) and used to render local times, so this is near-free — one header line, no extra API calls.
What it helps
- Correct weekday and correct "this week / next week / end of month" window math in the right zone.
- "When am I free today" can anchor to the real current time and correct weekday instead of an inferred one.
- Removes the wrong-day-of-week class of errors.
Scope
- Add a
formatAccountDateContext(timeZone, now?) helper (accepts an injectable now for testability).
- Inject it into
formatTaskList and formatScheduleList.
- Tests for the helper (fixed clock) and that both formatters include the line.
- Shared code, so it lands on both the stdio and Worker entry points.
Out of scope: a real free/busy endpoint (tracked separately; depends on Motion's API surface).
https://claude.ai/code/session_01HbZLaLAKnrR3ZoZkZUk1Dn
Problem
When answering date-relative questions ("what's due this week?", "when am I free today?"), the model has to reason about dates itself — computing an end-of-week date, mapping today to a schedule's weekday, anchoring "now". It knows the wall-clock date from its own context, but it does not know the account's timezone (e.g.
America/Denver).Observed in live testing against the deployed server (isolated fresh agents answering real prompts):
updatedTimestamp because nothing returns the current time.Note: relative filters the model delegates to the server (
dueDate:'today') already resolve correctly server-side via the account zone. The gap is the reasoning the model does on its own.Proposed fix (cheap, additive)
Surface an account-context line on responses the model already reads — task-list responses (
formatTaskList, used by bothlistandlist_all_uncompleted) and schedule responses (formatScheduleList):The timezone is already resolved (
resolveDisplayTimeZoneoff the cached schedules) and used to render local times, so this is near-free — one header line, no extra API calls.What it helps
Scope
formatAccountDateContext(timeZone, now?)helper (accepts an injectablenowfor testability).formatTaskListandformatScheduleList.Out of scope: a real free/busy endpoint (tracked separately; depends on Motion's API surface).
https://claude.ai/code/session_01HbZLaLAKnrR3ZoZkZUk1Dn