zjncs opened a new issue, #6665:
URL: https://github.com/apache/rocketmq-dashboard/issues/6665
## Problem
The alerts page's 本页 24h 触发 (Triggered in 24h on page) statistic parses each
rule's `lastTriggered` with `new Date(r.lastTriggered)`:
```ts
const triggered24h = rules.filter(
(r) => r.lastTriggered && new Date(r.lastTriggered).getTime() > dayAgo,
).length;
```
but `lastTriggered` is the backend's UTC wall clock serialized **without an
offset** (`RmqAlertRuleMapper.updateLastTriggered` stamps it UTC; the column
three hundred lines below parses the very same field with `formatUtcDateTime`,
whose doc comment exists for exactly this pitfall: "Alert APIs serialize UTC
LocalDateTime values without an offset, so normal Date parsing would
incorrectly treat them as browser-local timestamps").
So in a UTC+8 viewer every rule triggered 16–24 hours ago shifts 8 hours out
of the window and the statistic undercounts; in a UTC−8 viewer rules triggered
24–32 hours ago still count. The column and the statistic disagree about the
same timestamp on the same page.
## Expected behavior
The statistic parses `lastTriggered` the same way the column does — as UTC.
## Evidence
Reproduced with the frontend tests (`cd web && npx vitest run
src/pages/ops/__tests__/AlertsPage.test.tsx`): with `TZ=Asia/Shanghai`, a rule
triggered 20 hours ago (UTC, offset-less wire value) makes 本页 24h 触发 read `0`;
after parsing as UTC it reads `1`.
- `web/src/pages/ops/alerts.tsx` — the statistic's `new Date(...)` vs the
column's `formatUtcDateTime(record.lastTriggered)`;
- `web/src/utils/format.ts` — `formatUtcDateTime` documents and handles the
offset-less UTC wire format; nothing exposes that parse for numeric use.
--
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]
