[Bug]: Dashboard log timestamps display in browser local timezone instead of system/server time

[jhste102lab]

Client or integration

OpenCodex dashboard

Area

Dashboard

Summary

Log timestamps in the Dashboard (#logs tab) are stored as server-side Date.now() epoch milliseconds but rendered using toLocaleTimeString() / toLocaleString(), which converts them to the browser local timezone. For a local management dashboard expected to reflect the server state, this can cause confusion if the browser and server are in different timezones (e.g., remote access or containerized deployments).

Reproduction

1. Start ocx with the management API enabled
2. Open the dashboard in a browser that has a different timezone than the server
3. Navigate to the #logs tab
4. Observe that timestamps reflect the browser timezone, not the system/server timezone where opencodex is running

Source references

• Timestamp source: src/server/request-log.ts:272-274 — Date.now() for log IDs, src/server/request-log.ts:694 — start field set to wall-clock server time
• Timestamp DTO passthrough: src/server/management/shared.ts:143-162 — raw epoch ms passed to API response
• Display: gui/dist/assets/index-cmds12BG.js functions bc(), xc(), Gs(), Ks() — all use new Date(e).toLocaleTimeString(locale) / .toLocaleString(locale), which formats in browser local timezone

Expected behavior

Unclear whether this is intentional. If intentional (browser-local time is the standard web UX pattern), it is acceptable. If the intent is to show system/server time (since opencodex is a server-side tool and the dashboard is a management interface), the display should use a fixed timezone or UTC formatting.

Version

2.7.43

Operating system

Linux (WSL)

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[Wibias]

[shipping-github] Research review

Claim: Dashboard log timestamps render in the browser timezone via toLocale*, not server/system time.
Checked against: dev@be177ea5

Field	Finding
Still an issue on latest development?	yes (behavior unchanged); product intent unclear
Exact issue	gui/src/pages/Logs.tsx formatLogTimestamp / formatLogDateTime use toLocaleTimeString / toLocaleString on epoch ms
Fixed on development?	no
Open PR covering this?	none
Duplicate of?	none
Security relevance	none — n/a
Priority	low — UX confusion for remote TZ mismatch; browser-local is common web default
Verdict	Needs fix on development (or explicit docs that browser-local is intentional)

Evidence: gui/src/pages/Logs.tsx ~283–288; server stores Date.now() epoch and passes raw ms through management DTOs.
Gaps: No product decision recorded; if intentional, close as not a bug with docs note.

[Wibias]

[shipping-github] Opened PR #790 to address this.

[lidge-jun]

Fixed on codex/260731-pr-merge-round as a6d472e3f.

Dashboard log timestamps now render in the zone of the machine running the proxy, not the browser's. /api/settings reports the server's IANA zone and Logs.tsx passes it into formatLogTimestamp / formatLogDateTime; the detail dialog uses the same zone, so one request cannot show two different times on screen at once.

/api/logs is unchanged — still a bare array — because four suites read it that way. An unknown zone string falls back to browser-local instead of throwing, since a RangeError inside the formatter would take the whole row render down.

Regression coverage in tests/logs-timezone.test.ts: 00:30 UTC must read 9:30 in Seoul and 12:30 in UTC, so a dropped zone argument surfaces as a wrong hour rather than passing silently. Verified by ablation — removing the server field or the formatter argument each fails a test.

That branch is a staging line; this reaches dev and a release once the optimization work in flight there lands. PR #790 diagnosed this and is closed in favour of the narrower fix.