You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(gui): render dashboard log timestamps in the server's timezone (#725)
A proxy running in KST viewed from a UTC browser reported every request
nine hours off: `formatLogTimestamp` and `formatLogDateTime` called
`toLocaleTimeString(localeTag)` with no zone, so the viewer's machine
decided what time the server logged something.
The zone rides on `/api/settings`, which is already an object and already
flows through the GUI. PR #790 fixed the same defect by rewriting
`/api/logs` from a bare array into a `{timeZone, logs}` envelope -- while
leaving four suites that read that response as an array untouched
(server-auth:1623, claude-native-passthrough:119,
openai-provider-option-e2e:489, server-403-permission-e2e:86). It also
added a session-cache schema that accepts both the old and new shapes.
Curiously that PR already added `timeZone` to `/api/settings` and then
never read it, carrying one value over two routes.
Layout is untouched, which was the constraint here. The GUI diff is two
call sites gaining a third argument; every `className`, element and
stylesheet is byte-identical. `git diff -- gui/` filtered for
className/element/style changes returns the two timestamp lines and
nothing else.
The formatters swallow `RangeError`: a zone string this browser's ICU
build does not know would otherwise take the whole row render down, and a
timestamp in the wrong zone beats an empty log list. The fetch is a
one-shot on mount rather than part of the 2s log poll, since the server's
zone cannot change while the page is open, and an older proxy without the
field simply keeps browser-local formatting.
Tests, both verified by ablation rather than assumed:
- removing `timeZone` from /api/settings fails the settings test (4/1)
- dropping the formatter argument fails the rendering test (4/1)
That second one is the case #790's own test could not catch: it compared
the response to itself and passed with the production change reverted. The
new test fixes 00:30 UTC and asserts Seoul reads 9:30 while UTC reads
12:30, so an ignored argument shows up as a wrong hour. There is also a
test asserting /api/logs is still a bare array, placed at the source so
the contract fails here rather than in four unrelated suites.
The detail dialog gets the same zone; leaving it on browser time would put
two different times for one request on screen at once.
Co-authored-by: Wibias <37517432+Wibias@users.noreply.github.com>
0 commit comments