coder999o opened a new issue, #7318:
URL: https://github.com/apache/rocketmq-dashboard/issues/7318
### Before Creating the Bug Report
- [x] Searched all-state Issues and PRs, including the patches of the prior
certificate UTC fixes.
- [x] This is a RocketMQ Studio frontend defect.
- [x] Reproduced the current comparator on `rocketmq-studio` at
`127c47b06a268cc74224d5f34c56ec7c36ac0d55`.
### Studio Version
Source checkout of `rocketmq-studio`, commit
`127c47b06a268cc74224d5f34c56ec7c36ac0d55`.
### Runtime Environment
macOS, Node.js 23.7; JavaScript timezone `America/New_York`. Source-level
reproduction using the page's actual comparator, without a deployed
Studio/browser session.
### Connected RocketMQ Cluster
Not required: certificate records are Studio-local metadata and the defect
occurs when sorting the returned rows.
### Describe the Bug
The K8s certificate expiry column renders `notAfter` with
`formatUtcDateTime`, but sorts it with `Date.parse`. The backend serializes
certificate validity instants as offset-less UTC timestamps (`K8sCertService`
converts X.509 instants with `ZoneOffset.UTC`). Plain `Date.parse` instead
treats those strings as local wall clocks. Across a viewer's daylight-saving
gap this can reverse their order, so sorting by earliest expiry can prioritize
the later certificate.
### Steps to Reproduce
1. Use a viewer timezone of `America/New_York`.
2. List two certificate records with UTC `notAfter` values
`2026-03-08T02:30:00` and `2026-03-08T03:00:00`.
3. Sort the K8s certificate table by expiry ascending.
4. The existing comparator evaluates `Date.parse('2026-03-08T02:30:00') -
Date.parse('2026-03-08T03:00:00')` to `1800000`: the nonexistent local 02:30 is
normalized to 03:30. Interpreting both timestamps as UTC instead gives
`-1800000`.
### What Did You Expect to See?
02:30 UTC precedes 03:00 UTC in ascending expiry order, regardless of the
viewer's timezone; descending order reverses it.
### What Did You See Instead?
The earlier certificate is ranked after the later certificate in a
DST-observing timezone, even though the displayed times already use the correct
UTC interpretation.
### Additional Context
The fix can reuse `parseUtcDateTime`, which is already used by the column's
formatter. The existing missing/invalid timestamp fallback can remain
unchanged. Prior UTC fixes #5239 and #5511 change the renderer/serialization
but retain `Date.parse` in the sorter; #2560 only makes missing metadata safe.
This issue is specifically about expiry ordering.
### Are You Willing to Submit a Pull Request?
- [x] Yes, I am willing to submit a pull request.
--
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]
