unbridled-41 opened a new issue, #4840:
URL: https://github.com/apache/rocketmq-dashboard/issues/4840
### Studio Version
Branch `rocketmq-studio` (development trunk), commit `4c697f07`. The
affected code is unchanged on `master`'s frozen documentation point as well.
### Runtime Environment
- Browser: any viewer timezone other than UTC (verified with
`TZ=Asia/Shanghai`, deterministic under a fixed clock)
- Front-end only: `web/src/pages/ops/alerts.tsx`
### Describe the Bug
The alerts-page header stat "Triggered in 24h on page" (本页 24h 触发) compares
`new Date(r.lastTriggered).getTime()` against the wall clock:
```ts
const triggered24h = rules.filter(
(r) => r.lastTriggered && new Date(r.lastTriggered).getTime() > dayAgo,
).length;
```
`lastTriggered` is a UTC `LocalDateTime` serialized **without an offset
suffix**: the backend stamps it with `LocalDateTime.ofInstant(collectedAt,
ZoneOffset.UTC)` (`NativeAlertProcessor.emitLifecycleEvent`) and persists it
into `last_triggered VARCHAR(64)` (`db/schema.sql`). Without an offset suffix,
`new Date(...)` parses the value as **browser-local** time.
The Last-Triggered column on the same page deliberately parses the same
value as UTC via `formatUtcDateTime` (its comment states the convention), so
the two displays of the same field disagree for any viewer outside UTC:
- UTC+8: a rule that fired 23h ago UTC parses as 31h ago → the stat
**undercounts** (column shows "fired 23h ago", stat excludes the rule).
- UTC−8: the same firing reads as 15h ago → the stat **overcounts** (a
31h-old firing is counted).
### Steps to Reproduce
1. Run Studio with an alert rule on the alerts page; set the browser
timezone to Asia/Shanghai.
2. Have a rule whose `lastTriggered` is `'2026-08-23T13:00:00'` (UTC) and
view the page at `2026-08-24T12:00:00Z` (23h later).
3. Observe the Last-Triggered column rendering the firing as recent (UTC
parsing), while the "Triggered in 24h" stat does not count it (browser-local
parsing).
A deterministic automated version of this exists in PR #4826: the page-level
regression test pins `Date.now` at `2026-08-24T12:00:00Z` with
`TZ=Asia/Shanghai` and was verified to render `0` on the unfixed code and `1`
after the fix.
### What Did You Expect to See?
The stat counts rules whose `lastTriggered` (a UTC timestamp) falls inside
the last 24 hours, consistently with the Last-Triggered column, regardless of
the viewer's timezone.
### What Did You See Instead?
The count shifts by the viewer's UTC offset — undercounts in UTC+8,
overcounts in UTC−8.
### Additional Context
Proposed fix in PR #4826: extract the shared parse convention into
`parseAlertTimestamp()` in `web/src/utils/format.ts` (offset-less ⇒ UTC) and
use it for the stat; `formatUtcDateTime` routes through the same helper so the
two call sites cannot drift.
--
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]
