tju-yxq commented on issue #1816: URL: https://github.com/apache/rocketmq-dashboard/issues/1816#issuecomment-5269325906
## Clarification after re-checking I have narrowed the wording of this issue. The original text was too broad because it implied a live Aliyun environment had been used and that all Aliyun OpenAPI timestamp fields are universally documented as Beijing time. What is actually demonstrated by the current code and regression test is narrower: - `AliyunConverters` parses/format timestamp values in the `yyyy-MM-dd HH:mm:ss` shape handled by this provider. - These strings do not carry an offset at the converter boundary. - Using `ZoneId.systemDefault()` makes the epoch value depend on the Studio server's local timezone. - The PR makes this conversion explicit with `Asia/Shanghai` and adds a focused regression test. Validation added in PR #1817: ```bash mvn -DskipTests=false -Dtest=AliyunInstanceProviderTest#aliyunTimeConversionShouldUseShanghaiZoneIndependentOfJvmDefaultTest test ``` Result: `BUILD SUCCESS`, `Tests run: 1, Failures: 0, Errors: 0, Skipped: 0`. This remains a code-level timezone determinism fix, not a claim of live reproduction against a production Aliyun instance. -- 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]
