yyqdbngt opened a new issue, #5219:
URL: https://github.com/apache/rocketmq-dashboard/issues/5219
### Before creating
- [x] I have searched the existing issues and found no duplicate.
- [x] I have checked the latest `rocketmq-studio` branch where this problem
still exists.
### Bug report
**Which page or component**
- `web/src/components/QueueBrowser.tsx` — `formatTimeMs` (the queue browser
panel of the message page)
- `web/src/pages/instance/message.tsx` — local `formatTimeMs` (message
table, consume-time column, detail drawer, trace timeline)
**What happened**
The server sends `storeTime` as epoch millis (`MessageRecordVO.storeTime` is
a `long`), an absolute instant. The two views that render it each carry a
private formatter, and neither follows the project's timestamp convention
(`formatUtcDateTime`, established by #4222/#5197/#5204):
- QueueBrowser: `new Date(ts).toLocaleString('zh-CN', { hour12: false })` —
a **hardcoded Chinese locale**, so an English viewer gets `2026/9/30 10:05:32`,
in the **browser's own zone with no zone label**, and **milliseconds dropped**.
- message.tsx: local getters (`getFullYear()`/…), i.e. the browser's zone
again, unlabeled; milliseconds kept here only.
So the same message shows three different strings across the queue browser,
the table, and the detail drawer, and two operators in different zones read
different times off the same row with nothing telling them which zone.
**Steps to reproduce**
1. Open the message page of any instance and query a topic; note the store
time string (`2026-09-30 10:05:04.123`, browser zone, unlabeled).
2. Open the Queue Browser panel for the same topic and pull the same offset;
the same message now shows `2026/9/30 10:05:32` — Chinese locale pattern, no
milliseconds.
3. Set the browser language to English; the queue browser still renders
Chinese-style dates.
**Expected behaviour**
One shared formatter that renders the instant in the viewer's timezone
**with the zone labeled** (dense columns may drop the repeating suffix per the
documented `zone` option), keeps millisecond precision, and treats offset-less
string forms as UTC — exactly the contract `formatUtcDateTime` already applies
to alert timestamps.
**Environment**
branch `rocketmq-studio`, commit `4ee173ad`, verified by reading `web/src`
and running the affected vitest suites.
--
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]
