[I] [Bug] AliyunConverters uses systemDefault timezone for parsing Aliyun API timestamps [rocketmq-dashboard]

["tju-yxq (via GitHub)" <gi...@apache.org>]

tju-yxq opened a new issue, #1816:
URL: https://github.com/apache/rocketmq-dashboard/issues/1816

   AliyunConverters.parseTimeMillis and formatTimeMillis use ZoneId.systemDefault(). The Aliyun OpenAPI returns timestamps in Beijing time (UTC+8). If the Studio server runs in UTC or any other timezone, all parsed timestamps will be off by the timezone difference. For example, a message stored at 10:00 Beijing time would show as 02:00 on a UTC server. Fix: use ZoneId.of('Asia/Shanghai') for Aliyun timestamp parsing.


-- 
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: commits-unsubscribe@rocketmq.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [Bug] Aliyun timestamp conversion should not depend on JVM default timezone [rocketmq-dashboard]

["tju-yxq (via GitHub)" <gi...@apache.org>]

tju-yxq closed issue #1816: [Bug] Aliyun timestamp conversion should not depend on JVM default timezone
URL: https://github.com/apache/rocketmq-dashboard/issues/1816


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [Bug] Aliyun timestamp conversion should not depend on JVM default timezone [rocketmq-dashboard]

["tju-yxq (via GitHub)" <gi...@apache.org>]

tju-yxq commented on issue #1816:
URL: https://github.com/apache/rocketmq-dashboard/issues/1816#issuecomment-5283918491

   Fixed by #1978 (`ec912d32`). PR #1817 keeps the timezone behavior covered with a focused regression test.


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [Bug] AliyunConverters uses systemDefault timezone for parsing Aliyun API timestamps [rocketmq-dashboard]

["tju-yxq (via GitHub)" <gi...@apache.org>]

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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org