Timezone issue: Thread timestamps displayed in UTC instead of system timezone (Asia/Shanghai)

[cicav]

Describe the bug

When Knowledge Mem processes threads from Hermes Agent session database, the timestamps are displayed in UTC instead of the system timezone (Asia/Shanghai / CST, UTC+8).

To Reproduce

1. Have Hermes Agent sessions stored in ~/.hermes/state.db (Unix timestamps)
2. Enable autoThreadAnalysis: true in Knowledge Mem settings
3. Let Knowledge Mem process the threads
4. Check the generated memory files in OV storage

Expected behavior

Memory files should show timestamps in the system timezone (e.g., "Time: 2026-06-05 09:58" for a session that started at 09:58 CST).

Actual behavior

Memory files show UTC timestamps (e.g., "Time: 2026-06-05 01:58" for the same session, which is 8 hours behind CST).

Root cause analysis

The Hermes session database stores started_at as Unix timestamps (correct, timezone-agnostic). When Knowledge Mem reads these timestamps and formats them for display in the Time: line of memory files, it uses UTC instead of the system timezone.

Environment

• macOS with timezone set to Asia/Shanghai (UTC+8)
• Knowledge Mem desktop app version: 0.3.23
• Hermes Agent sessions stored in SQLite at ~/.hermes/state.db

Impact

All auto-backfilled memory entries have incorrect timestamps, making it difficult to correlate events with actual session times.

Workaround

A post-processing script that reads the correct CST times from the Hermes session DB and updates the Time: lines in memory files via the OV API.

Suggested fix

When formatting Unix timestamps for display, use the system timezone (via Intl.DateTimeFormat().resolvedOptions().timeZone in Electron, or equivalent) instead of defaulting to UTC.

[cicav]

Update: Second issue discovered — Scheduler not processing pending thread analysis

Problem

The pending_thread_analysis_events queue accumulates events but never processes them:

1. Pending events pile up: Started with 1 pending event, grew to 3 over 15+ minutes
2. 10-minute delay never triggers: pending_thread_analysis_delay_seconds: 600.0 is set, but after waiting well beyond 10 minutes, no processing occurs
3. Manual triggers don't work: POST /agent/trigger/insight-detection returns {"status": "queued"} but no task executes
4. All scheduled tasks stopped: last_executed timestamps are all from 2026-06-10 20:40-22:13 CST (yesterday), nothing runs today

Evidence

Pending events: 3
  Thread: 20260610_233024_4a2442
  Updated: 2026-06-11 08:13 CST (15+ minutes ago)
  
Last thread_synced: 2026-06-10 21:44 CST (10+ hours ago)
Last insight_detection: 2026-06-10 20:40 CST (11+ hours ago)

Expected behavior

After the 10-minute delay, pending thread analysis should execute and clear the queue.

Actual behavior

Events accumulate indefinitely. Scheduler appears to be stuck.

Workaround

Restarting the Knowledge Mem desktop app may reset the scheduler state.

Environment

• Knowledge Mem version: 0.3.23
• macOS with timezone Asia/Shanghai
• App processes running (no errors in logs)

[cicav]

Update: Restart did not fix scheduler

Restarted Knowledge Mem app. Pending events went from 3 → 1 (processed 2 on startup), but the remaining 1 is stuck again.

After restart:

• Pending events: 1 (was 3 before restart)
• Last thread_synced: still 2026-06-10 21:44 CST (10+ hours ago)
• Manual trigger POST /agent/trigger/insight-detection returns {"status": "queued"} but no task executes
• Waited 2+ minutes, no change

Conclusion: The scheduler is fundamentally broken. It accepts queued tasks but never executes them. This is not a transient issue — it persists across app restarts.

Workaround: None. The pending thread analysis queue will continue to accumulate events indefinitely.