zjncs opened a new issue, #6679: URL: https://github.com/apache/rocketmq-dashboard/issues/6679
## Problem `AuditService`'s own javadoc documents the storage convention clearly (MybatisPlus… `AuditService.csvHeader()`): > "Audit timestamps are stored as zone-less server-local values (whatever zone the server JVM/MySQL session runs in), so the exported timestamp column names the server's UTC offset — e.g. `timestamp(UTC+08:00)` — making the file interpretable without out-of-band timezone knowledge. The stored base itself is deliberately not converted; switching it to UTC is a repo-wide change that needs schema defaults and a backfill." The CSV export honors that reasoning. The **page rendering does not**: - `web/src/pages/ops/audit.tsx` renders the timestamp column with `formatDateTime` (a bare `new Date`/`Date.parse`, i.e. browser-local) — every audit time is shown shifted by the difference between the server zone and the viewer's zone. - `web/src/pages/instance/acl.tsx` renders rule/user `gmtCreate` with a local `formatDate(iso)` — same shift for the ACL tables' 创建时间. So whenever the browser zone differs from the server zone (e.g. a UTC container deployment viewed from UTC+8), the audit trail and the ACL tables show times up to many hours off, while the CSV export of the same rows is correct-by-labeling. Two views of the same row disagree. Note the column sorters are not affected (a uniform zone shift preserves order); it is the displayed wall clock that is wrong. ## Expected behavior Whichever direction the project prefers, the page should not silently reinterpret a server-local wall clock as the viewer's own. Options that do **not** touch the stored base (staying within the documented constraint): 1. Expose the server's zone offset once (e.g. a `serverZoneOffset` field on the audit page response, mirroring what `csvHeader()` already computes) and let the client convert for display. 2. Convert at the serialization boundary (`AuditRecordVO`/`AclRuleVO` builders) from the server zone to UTC and render with the existing `formatUtcDateTime` — storage stays zone-less server-local, the wire becomes UTC like the alert/K8s-cert/`lastTriggered` family that #5197 and friends already standardized. ## Evidence Reproduced by inspection (`cd web`): - `web/src/pages/ops/audit.tsx` line ~321: `render: (timestamp: string) => formatDateTime(timestamp)` where `formatDateTime` is the local-parse variant; - `web/src/pages/instance/acl.tsx` line ~576: `formatDate` uses `new Date(iso)`; - the contrast: `web/src/utils/format.ts` `formatUtcDateTime` exists precisely because "Alert APIs serialize UTC LocalDateTime values without an offset, so normal Date parsing would incorrectly treat them as browser-local" — the alert family got the UTC wire treatment, the audit/ACL gmt_create family never did. -- 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]
