1. 概述
用户对时间戳的要求往往很严格。他们期望我们的应用能自动识别其所在时区，并正确显示本地化的时间。
本文将深入探讨几种修改 JVM 时区的方法，同时也会揭示一些在时区管理中常见的“坑”。对于后端开发来说，时间处理看似简单，但一旦出问题就是线上事故，比如日志时间错乱、定时任务执行异常等，踩过的人才知道有多痛。
2. 时区基础
默认情况下，JVM 会从操作系统读取时区信息。
这些信息会被传递给 TimeZone 类，由它来存储当前时区并计算夏令时。
我们可以通过 TimeZone.getDefault() 获取当前运行环境的默认时区，也可以通过 TimeZone.getAvailableIDs() 获取 JVM 支持的所有时区 ID 列表。
Java 的时区命名遵循 tz database 的规范，格式通常为 区域/城市，例如：
Asia/ShanghaiAmerica/New_YorkEurope/London
✅ 推荐使用这种标准命名方式，避免歧义。
3. 修改 JVM 时区的方法
有三种主要方式可以改变 JVM 的默认时区，优先级依次递增。
3.1. 设置环境变量 TZ
最简单的方式是通过操作系统环境变量 TZ 来指定时区。
在 Linux 或 macOS 系统中，可以这样设置：
export TZ="America/Sao_Paulo"
设置完成后，JVM 会自动读取该值作为默认时区。验证代码如下：
Calendar calendar = Calendar.getInstance();
assertEquals(calendar.getTimeZone(), TimeZone.getTimeZone("America/Sao_Paulo"));
⚠️ 注意：这种方式依赖部署环境，适合容器化部署（如 Docker）时统一配置，但在多实例环境中容易因机器设置不一致导致行为差异。
3.2. 设置 JVM 参数 user.timezone
更常见且可控的做法是通过 JVM 启动参数设置时区：
java -Duser.timezone="Asia/Kolkata" com.company.Main
这个参数的优先级高于环境变量 TZ，也就是说如果两者都设置了，user.timezone 会生效。
此外，你也可以在程序启动早期动态设置系统属性：
System.setProperty("user.timezone", "Asia/Kolkata");
⚠️ 必须在使用任何日期时间类之前设置，否则可能无效（因为
TimeZone.getDefault()有缓存机制）。
验证方式相同：
Calendar calendar = Calendar.getInstance();
assertEquals(calendar.getTimeZone(), TimeZone.getTimeZone("Asia/Kolkata"));
✅ 建议在 Spring Boot 应用的启动类或配置类中尽早设置，确保全局一致性。
3.3. 在代码中直接设置默认时区
最高优先级的方式是通过 TimeZone 类直接修改默认时区：
TimeZone.setDefault(TimeZone.getTimeZone("Portugal"));
这条语句会强制覆盖 JVM 的全局时区设置，无论环境变量或 JVM 参数是什么。
验证结果：
Calendar calendar = Calendar.getInstance();
assertEquals(calendar.getTimeZone(), TimeZone.getTimeZone("Portugal"));
❌ 但这种方式要特别小心——它是全局生效的，会影响整个 JVM 中所有线程和组件。
如果你的应用是多租户或需要支持多种时区展示，这种“一刀切”的做法很容易引发问题。
4. 常见踩坑点
4.1. 避免使用三位字母时区 ID
虽然下面这样的写法能运行：
TimeZone.getTimeZone("CST"); // 可能是 China Standard Time，也可能是 Central Standard Time (US)
但官方明确不推荐使用三位缩写，因为它们具有歧义性：
| 缩写 | 可能含义 |
|---|---|
| IST | India Standard Time / Irish Standard Time / Israel Standard Time |
| CST | China Standard Time / Central Standard Time (US) |
| PST | Pacific Standard Time / Philippines Standard Time |
✅ 正确做法：始终使用 区域/城市 格式，如 Asia/Shanghai、America/Chicago
4.2. 全局时区设置的风险
上面提到的三种方式都会影响整个 JVM 的默认时区，属于全局状态变更。
但在现代应用中，尤其是 Web 服务：
- 用户来自不同时区
- 日志希望统一用 UTC 记录
- 数据展示需要按用户偏好转换
这时候设一个“全局时区”就没有意义了，反而容易导致混乱。
✅ 更好的实践是：不要依赖默认时区，而在每次处理时间时显式指定：
// 使用 ZonedDateTime 显式绑定时区
ZonedDateTime shanghaiTime = ZonedDateTime.now(ZoneId.of("Asia/Shanghai"));
// 或者用 OffsetDateTime 表示固定偏移
OffsetDateTime utcTime = OffsetDateTime.now(ZoneOffset.UTC);
✅ 推荐场景：
- API 接口返回时间统一使用 UTC 或带时区信息
- 前端根据浏览器自动转换
- 存储时间一律用
Instant或带时区类型，避免丢失上下文
5. 总结
本文介绍了三种设置 JVM 时区的方式，按优先级从低到高排列：
- 环境变量
TZ❌ 控制力弱，依赖部署环境 - JVM 参数
-Duser.timezone✅ 推荐，清晰可控 TimeZone.setDefault()⚠️ 谨慎使用，影响全局
同时强调了两个关键点：
- ✅ 使用标准时区名（如
Asia/Shanghai），杜绝CST、IST等歧义缩写 - ✅ 在复杂系统中避免依赖默认时区，优先使用
ZonedDateTime、OffsetDateTime显式传参
所有示例代码均已上传至 GitHub：https://github.com/baeldung/core-java-modules/tree/master/core-java-date-operations-2