Frun1na opened a new issue, #6532: URL: https://github.com/apache/rocketmq-dashboard/issues/6532
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `779b8c0e` deployed as: reproduced by a unit test that writes and reads back the exported sheet ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the Excel export row model browser (for UI issues): not applicable ### Connected RocketMQ Cluster RocketMQ version: not applicable — the export is built from a stubbed `DLQMessageVO` access mode: not applicable deployment: not applicable ### Describe the Bug The dead-letter Excel export renders a message's store time as a server-zone wall clock and never says which zone that is: - `DLQMessageExcelRow.java:41-42` formats with `"yyyy-MM-dd HH:mm:ss"`, and `from()` at `:75-76` converts the epoch with `Instant.ofEpochMilli(...).atZone(ZoneId.systemDefault())`, so the cell contains the server's local time. - The header that could have named the zone is a compile-time `@ExcelProperty("Store Time")` constant, and no column or sheet metadata carries a zone. - The console renders the same epoch in the viewer's zone (`web/src/utils/format.ts` formats epoch milliseconds with the browser's zone), and the other server-side exports do name their zone: the audit CSV writes `timestamp(UTC+08:00)` and the topic/group CSVs label their timestamp columns. Whenever the server zone differs from the viewer's zone (a container running with `TZ=UTC` is common), the exported sheet and the page silently disagree by the offset, with nothing in the file to tell which one is which. ### Steps to Reproduce The defect is pinned by a unit test; no live cluster is needed: ``` cd server mvn -B -ntp test -DforkCount=1 -Dtest=DLQMessageExcelRowTest ``` `shouldNameTheZoneOfTheStoreTimeItFormatsTest` exports one message with `storeTime = 1700000000000` and reads the "Store Time" cell back, asserting it equals the server-zone wall clock **plus** the offset `ZoneId.systemDefault().getRules().getOffset(instant)`. On a CST machine before the fix it fails with `expected: "2023-11-15 06:13:20 +08:00" but was: "2023-11-15 06:13:20"`. ### What Did You Expect to See? The exported cell should say which zone it was formatted in — either by naming the zone in the header (the CSV exports do that with `timestamp(UTC+08:00)`, but the Excel header is a constant) or by carrying the offset in the value, which is the option that fits the annotation-based header. ### What Did You See Instead? The cell contains a zone-less wall clock (`2023-11-15 06:13:20`), so the export cannot be reconciled with the console or with an export taken from another deployment without knowing the offset of the machine that produced it. ### Additional Context A fix with a regression test follows in a pull request. The wall-clock value is preserved; only the offset is added, so existing spreadsheets' column order and the other columns are unchanged. -- 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]
