wu-sheng opened a new pull request, #93: URL: https://github.com/apache/skywalking-horizon-ui/pull/93
## Why Reported on [apache/skywalking#13934](https://github.com/apache/skywalking/discussions/13934): a **custom** time range on the Traces tab returned no results, while "recent" worked. Root cause is a timezone bug — the custom range was sent as a browser-local **wall-clock string** the server re-read in its own timezone, so on a UTC-container deployment (browser ≠ server TZ) the window shifted by the UTC offset and landed on a time with no data. It reproduces only when browser and server timezones differ (so it looked fine in same-machine local dev). An audit of every custom-range surface found the same class of bug in **two** places, and confirmed the other six are already tz-proof: | Surface | Was | Now | |---|---|---| | Native traces | ❌ wall-clock string → `new Date()` in server TZ | ✅ epoch-ms → `fmtSecond` | | Layer logs | ❌ browser-local minute string → passthrough to OAP | ✅ epoch-ms → `fmtSecond` | | Zipkin, browser errors/logs, operate inspect, events, alarms, global picker, profiling | ✅ already absolute (epoch-ms / lookback) | unchanged | ## What Both buggy paths now send **absolute epoch ms** (`startMs`/`endMs`) and the BFF converts to OAP-server-local via `fmtSecond(ms, offset)` — the exact pattern the tz-proof surfaces already use. One consistent, timezone-proof way everywhere, no exceptions. - **Native traces** — `useLayerTraces` sends `startMs`/`endMs`; BFF `TraceListBody`/`explicitWindow`/`fetchNativeList` take epoch ms. - **Layer logs** — `LogQueryRequest`, `useLogTimeRange` (drops `toOapMinute`), `useLayerLogs`, `LayerLogsView`, and BFF `defaultWindow` all move to `startMs`/`endMs` + `fmtSecond`. - **Operate trace-inspect** (`explore.ts`) — drops its now-redundant `.toISOString()` round-trip and passes the epoch ms straight through. - The **metric→trace drill** rides the same trace send path, so its centered window is fixed by the same change. ## Validation `type-check`, `lint`, `build`, unit tests (BFF 172, UI 133) all green. The tz mismatch can't be reproduced in same-machine local dev; the fix is verified by construction (absolute instant → `fmtSecond(ms, serverOffset)`, identical to the browser-errors/events/alarms surfaces the audit confirmed correct). Worth a deployed smoke-check with browser TZ ≠ OAP TZ. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
