Fix UTC labeling of server build time in version output

[evanphx]

Summary

• Convert build timestamps to UTC before printing the UTC-labeled Built: line in miren version --server.
• Cover a non-UTC server timestamp, an already-UTC CLI timestamp, and an unknown build date.

Closes MIR-1848

Tests

• hack/it ./cli/commands (929 tests passed)
• make lint (0 issues)

[phinze]

Nice catch, and the CDT test case pins it down well. Non-blocking: upgrade_helpers.go has four more BuildDate.Format("... UTC") calls without a .UTC(). They're probably safe today because the inputs are already UTC, but tossing .UTC() on them would kill the whole class. Happy either way.

[evanphx]

Addressed Paul’s review: all four UTC-labeled build dates in upgrade_helpers.go now use .UTC() before formatting. Added a regression test using timestamps in opposite-offset zones so both current and latest output must show the correct UTC instant. Pushed in 4096053. hack/it ./cli/commands passed (930 tests); make lint passed (0 issues). No other actionable feedback was open.

— e + 🤖

[miren-code-agent]

🍪 biscuit: ✅ ready to merge — auto-review, non-blocking

This is ready, and I'm approving it: it's a small, display-only change, and I didn't find anything in it that needs another reviewer.

What changed: commit 4096053 follows Paul's suggestion and adds .UTC() to the four remaining BuildDate.Format("... UTC") calls in cli/commands/upgrade_helpers.go, at lines 134, 142, 167 and 168. The search I ran came back truncated, but every build-date format ending in a literal UTC that it returned now converts to UTC before formatting.

The new test: TestPrintVersionComparisonBuildDatesUTC gives the two timestamps opposite offsets (CDT −5 and JST +9), so leaving .UTC() off either one fails the test. The expected values are right:

• 12:48 CDT on the 14th is 17:48 UTC.
• 04:10 JST on the 15th is 19:10 UTC on the 14th.

Stdout swap in the test: the test temporarily replaces os.Stdout. That's safe here because nothing in cli/commands calls t.Parallel(). The output is also small enough to fit in the pipe buffer, so closing the writer before reading can't hang.

No new tests for two lines: the two changed lines in CheckIfUpgradeNeeded don't have their own test. They're the same one-token change as the lines that are tested, so I wouldn't hold the merge for it.

---

🍪 full review note · reviewed at 4096053 · comment /biscuit review to run biscuit again.