Execution timed out after Xms: JUnit 5 assertTimeout uses UTC clock by default

Execution timed out after Xms

JUnit 5’s assertTimeout reports failures with the message Execution timed out after Xms. Internally it measures elapsed time against Clock.systemUTC() unless a custom Clock is supplied via the overload that accepts a Clock parameter.

When tests perform date‑time conversions based on the JVM’s default time zone, the perceived wall‑clock duration may diverge from the UTC clock used for timeout measurement. This mismatch can make a test appear to pass or fail inconsistently across environments with different default zones.

Unresolved Design Question

JUnit 5 currently offers no annotation or configuration to set a per‑test or per‑class default time zone for all time‑based operations. Developers must manually adjust the JVM time zone or supply a custom Clock for each timeout assertion.

Questions for the community:

• How can a test suite consistently apply a non‑UTC clock to all assertTimeout invocations without per‑call changes?
• Is there a planned extension in JUnit 5 to expose a per‑test default time zone for timeout assertions?
• Would a global configuration of Clock for timeout assertions improve reliability of date‑time based tests?