mvn与gradlew启动JVM时的时区处理机制差异咨询

两者启动测试进程时的JVM时区加载、参数传递逻辑确实存在本质差异，这是同容器环境下两个构建工具输出时区不一致的根本原因。

Maven（mvn命令）的时区处理规则 #

• Maven主进程启动时，仅读取当前容器环境内显式配置的系统时区，默认取容器初始化时设置的UTC时区，不会主动解析挂载自宿主机的时区软链接、隐式透传的非标准时区变量。
• 执行测试时，若未在pom.xml的surefire/failsafe插件中通过argLine显式指定user.timezone参数，fork出的测试子JVM会完全继承主Maven进程的UTC时区配置。
• Maven对时区参数的读取优先级为：启动命令行传入的-Duser.timezone > MAVEN_OPTS环境变量 > JAVA_TOOL_OPTIONS环境变量 > 容器系统默认时区，不会额外扫描其他时区配置源。

Gradlew（Gradle Wrapper）的时区处理规则 #

Gradle的时区加载逻辑和Maven存在两处核心差异，直接导致其读取到宿主机时区：

• 启动时会优先扫描所有进程可见的时区相关环境变量，包括GitLab Runner启动容器时默认隐式透传的宿主机TZ环境变量——哪怕容器镜像默认时区配置为UTC，该透传变量也会被Gradle识别为最高优先级的时区配置。
• 测试任务fork子JVM时，除了继承主进程参数，还会主动扫描系统时区配置文件（/etc/timezone、/etc/localtime），如果这类文件是Docker从宿主机挂载的软链接，Gradle会直接解析软链接指向的宿主机时区配置，覆盖容器默认的UTC设置。
• Gradle默认不会强制对齐容器基础的UTC时区配置，只要存在更高优先级的可解析时区源，就会优先采用。

统一时区的可落地方案 #

不要依赖构建工具的默认时区读取逻辑，显式指定JVM时区是最稳定的方案：

• 针对Maven，在pom.xml的surefire插件中固定时区参数：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <argLine>-Duser.timezone=UTC</argLine>
    </configuration>
</plugin>

• 针对Gradle，在build.gradle的test任务中固定时区参数：

test {
    jvmArgs "-Duser.timezone=UTC"
}

• 也可以在容器全局配置JAVA_TOOL_OPTIONS="-Duser.timezone=UTC"环境变量，所有JVM进程启动时都会优先读取该参数，彻底屏蔽不同构建工具的逻辑差异。

内容的提问来源于stack exchange，提问作者MiklosBalazsi