Observed behavior: SQLite message createdAt values are interpreted in the host timezone, while summary timestamps are explicitly interpreted as UTC. On a non-UTC host this shifts serialized message timestamps. This is a distinct runtime issue discovered during documentation-only Chore #849 planning.
Expected behavior: Interpret SQLite's timezone-less UTC storage timestamps as UTC, while preserving already timezone-qualified values. Message and summary timestamps representing the same instant should agree across host timezones.
Root cause: At ec57cea0, src/db/migration.ts defines messages.created_at with datetime('now'); message row/search mappers in src/store/conversation-store.ts call new Date(row.created_at). In contrast, src/store/summary-store.ts:167-175 normalizes the SQLite form with an explicit Z before parsing. The SQLite UTC text is otherwise parsed as local time by JavaScript.
Safe reproduction: Run TZ=America/Sao_Paulo node -e 'console.log(new Date("2026-09-06 07:20:00").toISOString(), new Date("2026-09-06T07:20:00Z").toISOString())'. Observed outputs: 2026-09-06T10:20:00.000Z and 2026-09-06T07:20:00.000Z. Source inspection confirms the first parser is used for message records/search results. Add a future isolated SQLite fixture test in a non-UTC child process. No real user data, daemon, credentials, or global installation was touched.
Scope: P2 follow-up outside frozen S3 / Epic #968, originating #849 plan GLM/Opus review. Do not fold into #849's response-documentation correction. Duplicate search found #794 and #877 concern bound parsing/year range, not host-local interpretation of stored message timestamps. Claims about additional filtering effects remain unverified and are not asserted here.
Environment:
- Agent: GLM-5.3 Max / Opus 5 medium review, Astra owner verification
- Connector: static source and isolated synthetic Node date parsing
- OS: Fedora Linux; TZ=America/Sao_Paulo
Originating documentation PR: #1026 corrects #849's response documentation; it does not fix this timestamp parsing defect.
Observed behavior: SQLite message
createdAtvalues are interpreted in the host timezone, while summary timestamps are explicitly interpreted as UTC. On a non-UTC host this shifts serialized message timestamps. This is a distinct runtime issue discovered during documentation-only Chore #849 planning.Expected behavior: Interpret SQLite's timezone-less UTC storage timestamps as UTC, while preserving already timezone-qualified values. Message and summary timestamps representing the same instant should agree across host timezones.
Root cause: At
ec57cea0,src/db/migration.tsdefines messages.created_at withdatetime('now'); message row/search mappers insrc/store/conversation-store.tscallnew Date(row.created_at). In contrast,src/store/summary-store.ts:167-175normalizes the SQLite form with an explicit Z before parsing. The SQLite UTC text is otherwise parsed as local time by JavaScript.Safe reproduction: Run
TZ=America/Sao_Paulo node -e 'console.log(new Date("2026-09-06 07:20:00").toISOString(), new Date("2026-09-06T07:20:00Z").toISOString())'. Observed outputs:2026-09-06T10:20:00.000Zand2026-09-06T07:20:00.000Z. Source inspection confirms the first parser is used for message records/search results. Add a future isolated SQLite fixture test in a non-UTC child process. No real user data, daemon, credentials, or global installation was touched.Scope: P2 follow-up outside frozen S3 / Epic #968, originating #849 plan GLM/Opus review. Do not fold into #849's response-documentation correction. Duplicate search found #794 and #877 concern bound parsing/year range, not host-local interpretation of stored message timestamps. Claims about additional filtering effects remain unverified and are not asserted here.
Environment:
Originating documentation PR: #1026 corrects #849's response documentation; it does not fix this timestamp parsing defect.