123123213weqw opened a new pull request, #5732: URL: https://github.com/apache/rocketmq-dashboard/pull/5732
## What is the purpose of the change `AliyunConverters.parseDateTime` returned Aliyun's UTC+8 wall clock as a zone-less `LocalDateTime` without converting it — unlike `parseTimeMillis` in the same file, which correctly reads those strings in `Asia/Shanghai` (per the comment above `ALIYUN_TIME_ZONE`). The `gmtCreate`/`gmtModified` values of Aliyun topics and consumer groups therefore drift by the zone difference from every timestamp Studio itself writes and from the epoch-based message/trace times of the same instance whenever the server zone is not UTC+8 — two timestamps of the same Aliyun instance rendered hours apart. The Tencent provider already relabels its unzoned formats through `ZoneId.systemDefault()`; Aliyun was the outlier. ## Brief changelog - Convert the parsed wall clock into `ZoneId.systemDefault()` in `parseDateTime`, mirroring `TencentInstanceProvider`. A server already running Asia/Shanghai produces identical values to before. ## Verifying Red-first: `AliyunConvertersTest.parseDateTimeShouldRelabelAliyunWallClockIntoTheServerZoneTest` fails on `rocketmq-studio` (10:00 kept instead of 02:00 UTC) and passes with the change; the Asia/Shanghai case and null/unparseable cases are pinned too. `mvn test -Dtest='AliyunConvertersTest,AliyunInstanceProviderTest'` green (53 tests). -- 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]
