Repository navigation
[Bug]: Dashboard log timestamps display in browser local timezone instead of system/server time #725
Description
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
- Start
ocxwith the management API enabled - Open the dashboard in a browser that has a different timezone than the server
- Navigate to the
#logstab - 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—startfield 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.jsfunctionsbc(),xc(),Gs(),Ks()— all usenew 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.
Activity
github-actions commentedon Jul 30, 2026
Automated translation bookkeeping — detected language: unknown.
Wibias commentedon Jul 30, 2026
[shipping-github] Research review
Claim: Dashboard log timestamps render in the browser timezone via
toLocale*, not server/system time.Checked against: dev@be177ea5
gui/src/pages/Logs.tsxformatLogTimestamp/formatLogDateTimeusetoLocaleTimeString/toLocaleStringon epoch msEvidence:
gui/src/pages/Logs.tsx~283–288; server storesDate.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 commentedon Jul 30, 2026
[shipping-github] Opened PR #790 to address this.
fix(gui): render dashboard log timestamps in the server's timezone (#725
lidge-jun commentedon Jul 31, 2026
Fixed on
codex/260731-pr-merge-roundasa6d472e3f.Dashboard log timestamps now render in the zone of the machine running the proxy, not the browser's.
/api/settingsreports the server's IANA zone andLogs.tsxpasses it intoformatLogTimestamp/formatLogDateTime; the detail dialog uses the same zone, so one request cannot show two different times on screen at once./api/logsis 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 aRangeErrorinside 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
devand a release once the optimization work in flight there lands. PR #790 diagnosed this and is closed in favour of the narrower fix.fix(gui): gate the timezone setter so a stale response cannot land
fix(gui): render dashboard log timestamps in the server's timezone (l…
test(logs): expect /api/logs envelope in lidge-jun#725 timezone suite
fix(gui): gate the timezone setter so a stale response cannot land