123123213weqw opened a new issue, #5227:
URL: https://github.com/apache/rocketmq-dashboard/issues/5227

   ### 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**
   
   - 
`server/src/main/java/org/apache/rocketmq/studio/cluster/k8s/K8sCertService.java`
 — X.509 validity conversion and the service's default clock
   - `web/src/pages/cluster/certs.tsx` — the 到期时间 (expiry) column
   
   **What happened**
   
   Certificate validity is an absolute, zone-free instant, but two zones get 
applied to it:
   
   1. `K8sCertService` converts the parsed X.509 dates with 
`LocalDateTime.ofInstant(..., ZoneId.systemDefault())` (lines 93-94), so the 
stored/serialized `notBefore`/`notAfter` is a wall time in the **server's** 
zone, offset-less on the wire.
   2. The console renders it with `formatDateTime`, whose `new 
Date(offsetLessString)` parses it in the **browser's** zone.
   
   The shown expiry is therefore offset by (server zone − viewer zone): the 
same certificate shows different expiries for two operators, and on any 
deployment whose server zone is not the viewers' zone the value is simply 
wrong. The service's default `Clock.systemDefaultZone()` also makes the 
expiry-status computations speak a different wall clock than the stored values 
once those are UTC.
   
   #4949 established the project convention — offset-less timestamps are 
written on the UTC clock and read as UTC by the console — and the alert 
surfaces already read through `formatUtcDateTime` for exactly this 
serialization.
   
   **Steps to reproduce**
   
   1. Run the server with `TZ=Asia/Shanghai`, browse with a UTC workstation, 
create a certificate from a supplied PEM.
   2. The expiry shown differs from the certificate's actual `notAfter` by 8 
hours.
   
   **Expected behaviour**
   
   The X.509 instants are expressed in UTC (`ZoneOffset.UTC`), the service's 
default clock is UTC so status/freshness match the stored wall times, and the 
console renders the column through `formatUtcDateTime`.
   
   **Environment**
   
   branch `rocketmq-studio`, commit `4ee173ad`; server tests verified red under 
`TZ=Asia/Shanghai` against the unfixed conversion.


-- 
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]

Reply via email to