tju-yxq opened a new issue, #5587:
URL: https://github.com/apache/rocketmq-dashboard/issues/5587
## Problem
Every zoneless datetime in the ops surfaces is written as **UTC** — alert
lifecycle events (`NativeAlertProcessor`: `LocalDateTime.ofInstant(collectedAt,
ZoneOffset.UTC)`), silence windows (`AlertSilenceService`), notification outbox
times (`utcNow()`), session timestamps (`AuthService`), and query history
(`Clock.systemUTC()`). The frontend confirms the contract: those surfaces
render with `formatUtcDateTime`, which appends `Z` to zoneless strings. The
default JDBC URL even pins `serverTimezone=UTC`.
The two DLQ paths are the **sole outliers** using `ZoneId.systemDefault()`:
1. `provider/apache/RocketMQDLQProvider.java:157-158` — the group list's
`lastEnqueueTime` ("最近入队时间").
2. `instance/dlq/DLQMessageExcelRow.java:59-60` — the Excel export's "Store
Time" column.
On any deployment whose JVM zone is not UTC (typical bare-metal CN installs,
UTC+8) with an operator in another zone, the DLQ timestamps are shifted
relative to every other time in the console: an alert and a dead-letter message
from the same instant display times 8 hours apart. The DLQ page also renders
these with the plain `formatDateTime` (no zone label), so the shift is
invisible rather than explained.
## Expected Behavior
Both conversions use `ZoneOffset.UTC`, aligning the DLQ surfaces with the
app-wide zoneless-UTC contract. On a UTC-JVM deployment nothing changes; on
non-UTC JVMs the DLQ times now agree with the alert/silence/session times and
with the Excel export of every other surface.
--
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]
