[Bug] DLQ timestamps shift with the JVM zone while every other zoneless datetime is UTC

Open Beginner friendly
  • Is something wrong?
#5,587 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

@tju-yxq is already working on this.

Since Oct 4, 2026.

  • #5588 by @tju-yxq — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
backend

Research direction

Read the conversions at provider/apache/RocketMQDLQProvider.java:157-158 and instance/dlq/DLQMessageExcelRow.java:59-60. Check how each timestamp is converted, then verify both use UTC; done means DLQ timestamps no longer depend on the JVM's default zone and align with the app-wide zoneless-UTC contract.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Java
Stars
1.4k
Forks
718
Avg merge
3d 16h
Merged PRs (30d)
215

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/rocketmq-dashboard

All issues in apache/rocketmq-dashboard

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.