GitHub and Jira write their timestamps to the second

[rollroyces]

GitHub and Jira issue connectors write their timestamps to the second (2026-08-18T16:18:27Z) instead of cutting them to the UTC day, so a fact extracted from "Opened by X on …" or a history line starts at the moment the event happened.

Why

0013 §6 deliberately cut connector timestamps to the day until three pieces existed: the precision ladder with its truncation CHECK, the prompt rule for zoned clock times, and a rendering branch. 0024 delivered all three, and its §3 names a ticket's updated_at as a time that reaches the second, but the connectors kept writing %Y-%m-%d. That cut has two real costs:

• a start can be up to 24 hours early (an event at 23:59:59Z counts as holding from 00:00Z that day);
• two events on the same UTC day look simultaneous, which queues a conflict.

What changed

• github_issues::render and jira_issues::render write every timestamp (opened/reported, closed/resolved, history lines, comment headers) through time_text::world(t, Some("second")). Jira's milliseconds are not written; the extractor reads the second back.
• 0013 §6 carries a dated revision note, and its status line (plus the README index row) now says the timestamps reach the second. The roadmap item "Time to the moment" is removed from the README.

Decisions on the questions this PR first raised

The first version of this PR added config.precision (default day) and a design doc with five open questions. After review:

1. No setting, and no day default. Precision is a property of the data. A default of day would keep the cut this PR set out to remove, and nothing in the UI exposes the key.
2. No backfill. Existing day-precision facts are still true ("the day is known"), and an issue that changes again is re-rendered on its next sync.
3. Typo policy: moot without a setting.
4. Document date: in the prompt stays a day. It anchors relative phrases like "last March", and the full instant is already stored in documents.doc_time. Changing it would affect every document and would need a recall-bench round.
5. The JQL cursor needs no change. It already uses %Y-%m-%d %H:%M from our own last_sync_at clock, independent of how the body is rendered.

The design doc under .roadmap-proposals/ is removed; this repository keeps such reasoning in docs/decisions, and 0024 already decided the substance.

Verification

• a_time_in_the_document_reads_back_to_the_second (GitHub): an event at 2026-09-05T23:59:59Z is rendered with that string, and utopia_extract::parse_time reads it back at second precision.
• a_time_in_the_document_is_written_to_the_second (Jira): +0000 and +0800 timestamps with milliseconds render as …Z to the second.
• Existing renderer tests now expect second-precision strings.
• During review, a scripted extraction endpoint on a real server stored labeled at 2026-09-05T23:59:59Z / second from a document rendered this way, versus 2026-09-05T00:00:00Z / day before. That run used the first version of the renderer, which writes the same strings.
• utopia-server 280 passed, utopia-core 23 passed on a migrated database; clippy --workspace --all-targets -D warnings and fmt are clean.

🤖 Generated with Claude Code

[WaylandYang]

@rollroyces thanks for picking up the roadmap item and for mapping every site so carefully. Before this can merge there is a decision to settle and a few things to fix.

The day cut is a recorded decision. 0013 decision 6 cuts connector timestamps to the day on purpose: precision = day says the day is known, both connectors are resyncable so nothing is lost, and world time renders in UTC by design, so a UTC+8 reader seeing 2026-09-05 is expected. It adds instant only when someone needs local business days or a source whose events cluster around midnight, and 0016 repeats that trigger. The PR doesn't name such a case yet. If you have one, please describe it in an issue; that is what moves this forward.

When it lands, it doesn't need a knob. The CHECK constraint and the extraction side already take seconds (migration 0033, parse_time), so the remaining piece is rendering: a source that has the instant can write the instant. A per-source precision key that defaults to day keeps the old shape for everyone who doesn't know the key exists, and it brings rules of its own (typos fall back to day, hour/minute/second collapse to instant). Please write the instant directly in both github_issues and jira_issues (the JQL cursor can stay as it is), and update 0013's status line and decision 6 plus the README roadmap line in the same PR.

To fix in the current diff

• time_text::world: Some("instant") | None and Some(_) both return instant(t). The comment says parse_time tells them apart, but the strings are identical, so the new arm can go.
• The PR body and checklist say render() is kept as a back-compat alias; the code removes it. The removal note is left as a /// paragraph on top of the next function's doc comment (github_issues.rs:201).
• The comments cite #610 as the proposal. #610 is about an upload's written date, a separate question.
• .roadmap-proposals/instant-precision.md shouldn't go into the repo. Design notes live in docs/decisions/, and here the place is 0013 itself.

Worth a line in the description: GitHub sync is incremental (since), so after deploy only issues updated later are re-rendered and re-extracted. A base carries day-precision and second-precision documents side by side until a full resync, which re-extracts every issue.

[WaylandYang]

@rollroyces thanks for tracing every timestamp site. Your end-to-end claim holds: we checked it with a scripted extraction endpoint, and a rendered …T23:59:59Z lands at second precision. We changed the shape before merging, though, and I pushed the change to your branch (459a8d8):

• No setting. 0024 §3 already decided that a ticket's timestamps reach the second, and 0013 §6 only waited for that ladder. A per-source switch that defaults to day would keep the cut in place for everyone, and no UI exposes the key. GitHub and Jira now always write time_text::world(t, Some("second")). Jira is in the same cut because it has the same four call sites.
• The design doc is gone. .roadmap-proposals/ isn't a convention here; reasoning lives in docs/decisions. 0013 §6 gets a dated revision note instead. Your five questions are answered in the updated description.
• One correction to the motivation. World time renders in UTC at every precision (0013 §6, fmtTime), so a UTC+8 reader never sees a shifted date. The real costs are a start up to 24 hours early, and false simultaneous conflicts between events on the same UTC day.

🤖 Generated with Claude Code