yyqdbngt opened a new pull request, #2943: URL: https://github.com/apache/rocketmq-dashboard/pull/2943
## Summary `K8sCertService.createCert` converted the parsed PEM's `notBefore`/`notAfter` instants with `ZoneId.systemDefault()`, while every other time computation in the service (`refreshExpirationState`, `listCerts`, renewal) works against `LocalDateTime.now(clock)` in the clock's zone. The conversion now uses `clock.getZone()`, so stored validity windows stay comparable with the expiry checks even when the JVM default zone differs from the service clock. ## Why The certificate validity instants are absolute, but `LocalDateTime` is zone- relative. Mixing `ZoneId.systemDefault()` at write time with the clock zone at read time shifts the stored dates by the zone offset whenever they differ, so a cert can appear expired (or not) on the wrong day after a timezone change or when the service clock is pinned to a specific zone. ## Testing ``` cd server && mvn -Dtest="K8sCertServiceTest" test ``` Tests run: 30, Failures: 0, Errors: 0, Skipped: 0 New regression test `createCertShouldDerivePemValidityInTheClockZone` pins the clock to a zone that always differs from the JVM default and asserts the stored `notBefore`/`notAfter` match the certificate's absolute instants rendered in the clock zone. -- 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]
