gmail listings emit a naive "2026-07-28 03:36" date with no offset, derived from the sender's Date header

[chrischall]

gog gmail messages/threads JSON emits date in listDateLayout ("2006-01-02 15:04"), which carries no offset:

{ "id": "19fa6c3d5a030951", "date": "2026-07-28 03:36", "subject": "…" }

A caller reading that has to already know which zone gog was configured for. Get it wrong and the value can land on the wrong calendar day, not merely the wrong hour — 2026-07-28 03:36 rendered in UTC is 2026-07-27 23:36 Eastern, a different date. That is the difference between "this went out Tuesday" and "this went out Monday night", which in a legal or scheduling record is the whole question.

This bit in practice on a headless deployment where nothing set GOG_TIMEZONE, so time.Local was UTC and the naive value silently meant UTC while every consumer read it as local.

Two things would fix it:

1. Carry an explicit offset. The compact date column is good for humans and should stay, but JSON consumers need an unambiguous value.

2. Prefer internalDate over the Date: header. formatGmailDateInLocation parses the header written by the sending client, which varies in format and offset and is occasionally just wrong. The Gmail API's internalDate is its own receipt timestamp (epoch ms, UTC) and is authoritative.

Proposal: add a dateIso field (RFC3339, from internalDate, rendered in the configured location) alongside the existing date, leaving current output and the human table untouched. Purely additive, so nothing that reads date today breaks.

Happy to send a PR — I have it implemented with tests.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 2, 2026, 3:13 AM ET / 07:13 UTC.

Summary
This issue remains necessary: current main and released v0.34.1 still emit Gmail listing dates as offset-free, minute-level values derived from sender Date headers. The focused, proof-positive implementation at #946 already owns the change, so this issue should stay open for maintainer approval of the durable JSON contract rather than receive another fix PR.

Reproducibility: yes. — current source deterministically renders sender-header dates as 2006-01-02 15:04, which omits an offset and seconds. The linked PR additionally contains redacted after-fix live Gmail JSON evidence for both message and thread paths.

Maintainer decision needed

Question	Recommendation
Should Gmail JSON listings add optional internalDateIso, sourced from Gmail internalDate, while retaining the sender-header-derived date field unchanged?	Approve the additive contract: Accept internalDateIso as a source-specific optional field while preserving the existing date output for scripts.

Why: The implementation is bounded and has live proof, but the field name, timestamp source, precision, and timezone behavior establish a durable public JSON API.

Next step
The linked open PR already owns the implementation; the remaining action is maintainer approval of the public JSON contract, not another repair branch.

Review details

Best possible solution:

Accept a source-specific optional internalDateIso contract in the linked PR, preserve the legacy date field byte-for-byte, and merge the focused implementation with its selector and precision regression coverage.

Do we have a high-confidence way to reproduce the issue?

Yes — current source deterministically renders sender-header dates as 2006-01-02 15:04, which omits an offset and seconds. The linked PR additionally contains redacted after-fix live Gmail JSON evidence for both message and thread paths.

Is this the best way to solve the issue?

Yes, conditionally — a source-specific additive field is narrower and safer than changing date in place, but maintainers need to approve the durable JSON contract before it lands.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• internalDateIso becomes a public JSON compatibility commitment: its source semantics, omission behavior, timezone rendering, and millisecond precision need maintainer approval before merge.

Codex review notes: model internal, reasoning high; reviewed against 4985e2681e31.

Label changes

Label justifications:

• P2: This is a bounded Gmail JSON-output improvement with concrete downstream automation impact but no demonstrated urgent outage.
• impact:other: The affected behavior is ambiguous timestamp interpretation in exported Gmail records, outside the more specific owned impact classes.

Evidence reviewed

What I checked:

• Current main retains the reported behavior: The shared listing layout is 2006-01-02 15:04; both message and thread listings populate date from the sender Date header, and neither JSON item exposes an offset-bearing internal timestamp. (internal/cmd/gmail_date.go:11, 4985e2681e31)
• Current tests define the existing lossy contract: The timezone tests expect minute-only strings and confirm that the current implementation converts a parsed sender header into a configured location, without serializing an offset or seconds. (internal/cmd/gmail_test.go:69, 4985e2681e31)
• Released provenance: The relevant current lines blame to the v0.34.1 release commit, and inspecting that release’s formatter confirms the same offset-free listing layout shipped. (internal/cmd/gmail_messages.go:260, 4747fb05a429)
• Open candidate fix: feat(gmail): add offset-bearing internalDateIso to message and thread listings #946 explicitly closes this issue and, per its body and the contributor’s follow-up, adds a source-specific internalDateIso field, requests internalDate in the message partial-response mask, and includes targeted regression coverage plus redacted live Gmail JSON output. (ecb04b916247)
• Vision fit: The repository VISION.md supports incremental Gmail capabilities and stable scriptable JSON output, but asks for discussion before adding new API surfaces. (VISION.md:7, 4985e2681e31)
• Maturity score unavailable: The required maturity shortlist helper could not read qa/maturity-scores.yaml because that scorecard is absent from this checkout, so no maturity label is proposed.

Likely related people:

• Peter Steinberger: Current blame attributes the shared formatter and both affected message/thread date assignments to the v0.34.1 Gmail implementation. (role: original Gmail listing implementation author; confidence: high; commits: 4747fb05a429; files: internal/cmd/gmail_date.go, internal/cmd/gmail_messages.go, internal/cmd/gmail_thread_search_helpers.go)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.