[Hanabi9248]

CommonUtil.stringToDate treats the trailing Z as a literal but leaves the formatter in the JVM default time zone. For example, 2026-09-23T14:00:00Z becomes 06:00 UTC on an Asia/Shanghai server.

isAllPodRebuild compares that result with the instance update time during upgrade and autoscaling callbacks. A newly started pod can therefore be treated as older than the update. Set the formatter to UTC so the comparison uses the actual start instant.

The regression tests cover UTC, Asia/Shanghai and America/Los_Angeles, including pod timestamps on either side of an instance update. Running them against the original implementation produces four failures out of six; all six pass with this change.

Validation: compiled the real utility classes and ran JUnit 4 with Java 8 target bytecode on JDK 25 (Lombok 1.18.42 for that compiler). The Maven reactor test attempt stopped during dependency/plugin downloads with TLS handshake failures; a complete Maven build and Kubernetes integration test have not run.

[Hanabi9248]

Could a maintainer review this UTC parsing fix and approve the pending Code Format Check and Unit Test workflows when convenient? The six focused JUnit regressions pass locally across the tested server time zones. The full Maven build was blocked by dependency-download TLS failures, so the upstream checks would help complete validation. Happy to adjust the approach based on review.

[Hanabi9248]

Following up with a CI status update: the Code Format Check and Unit Test runs have now expired while waiting for maintainer approval. Both summaries report that approval was required but not granted before expiry, and neither run executed any jobs, so they provide no source-level failure diagnostics.

When convenient, could a maintainer review the UTC parsing change and authorize fresh workflow runs? The source is unchanged at 35a8d0e16040e3c1599095044e0ebe64e954c780; I can address any concrete review or test findings.