Email timestamps sometimes show in UTC instead of local time

[Al629176]

Summary

Email timestamps are sometimes reported in UTC instead of the user’s local timezone, causing the agent to describe email recency incorrectly.

Problem

When the agent fetches recent emails, it may return the correct email data but mention a received time in UTC rather than the user’s local timezone. In the reported case, the agent initially described an email time as 10:33am, then later corrected that it was 10:33 UTC and equivalent to 5:33 PM local time.

Expected behavior: user-facing email timestamps should be converted to the user’s local timezone before the agent uses them in summaries, comparisons, or “latest email” reasoning.

Steps to reproduce:

1. Open OpenHuman chat.
2. Ask the agent to fetch the latest email or recent emails.
3. Compare the timestamp shown by the agent with the local email timestamp.
4. Observe that the agent may mention the UTC timestamp instead of the local timestamp.

Version / platform: desktop app; exact version and OS not provided.

Impact: users may think the agent missed newer emails or misunderstood recency because the displayed timestamp is several hours off.

Solution (optional)

Normalize email timestamps at the integration/tool-result boundary or before rendering/agent summarization. Tool results should include both the original provider timestamp and a user-local formatted timestamp, with the agent instructed to use local time for user-facing responses.

Acceptance criteria

• Local timestamps shown — Email times in agent responses are displayed in the user’s local timezone.
• UTC preserved internally — Raw UTC/provider timestamps remain available for sorting and debugging where needed.
• Recency reasoning correct — “Latest email” and “emails after X time” logic compares timestamps consistently and does not mix UTC with local time.
• Timezone context explicit — If a timestamp must mention UTC, the response clearly labels it as UTC and provides local time.
• Regression safety — Unit or integration coverage verifies email timestamp conversion and sorting across timezone offsets.
• Diff coverage ≥ 80% — the fix PR meets the changed-lines coverage gate (Vitest + cargo-llvm-cov, enforced by .github/workflows/coverage.yml).

Related

• User report: agent fetched the expected email but initially mentioned the timestamp in UTC instead of local time.