Handling System Time Zone Leakage in JUnit 5 Parameterized Tests

When validating date conversion logic across multiple regional time zones using JUnit 5 @ParameterizedTest, there is a risk of environmental leakage. If the application under test relies on ZoneId.systemDefault(), tests may pass on a local developer machine but fail in a CI/CD pipeline configured to UTC.

While java.time provides the necessary logic for offsets, JUnit 5 does not natively isolate the JVM's default time zone per test method. This creates uncertainty when verifying that a conversion behaves consistently regardless of the host environment's regional settings.

Which strategy is most effective for ensuring deterministic time zone isolation within a Jupiter test suite without manually resetting the global JVM state? Does JUnit 5 provide a recommended extension pattern for mocking the system clock to prevent these discrepancies?