Java 的 TimeZone 类是时区规则的静态快照，不处理夏令时切换也不感知系统时区变更；它为抽象类，须通过工厂方法如 TimeZone.getTimeZone("Asia/Shanghai") 获取实例，禁用 new 和 GMT 偏移字符串；getOffset() 返回毫秒偏移，依赖 JVM 内置 tzdata 版本，未来日期可能因规则过时而计算错误；与 java.time.ZoneId 混用易致 DST 行为不可靠，应优先使用 ZoneId 和 ZonedDateTime；JVM 启动后 TimeZone.getDefault() 不自动响应系统时区变更。
Java 的 TimeZone 类本身不处理夏令时切换逻辑，也不感知系统时区变更，它只是时区规则的静态快照封装 —— 真正决定时间偏移的是底层 ZoneId 和 java.time 的规则数据库。
为什么 new TimeZone() 不能直接用
TimeZone 是抽象类，无法实例化。所有获取方式都依赖工厂方法，且多数已被标记为过时（@Deprecated）：
-
TimeZone.getTimeZone("GMT+8")：解析为固定偏移，忽略夏令时，且不推荐用于生产 -
TimeZone.getTimeZone("Asia/Shanghai")：正确方式，基于 IANA 时区 ID 查找规则（如 JRE 内置的 tzdata） -
TimeZone.getDefault()：返回 JVM 启动时读取的系统默认时区，后续系统时区变更不会自动更新
getOffset() 返回值为什么有时不准
getOffset(long date) 计算毫秒时间戳对应时刻的 UTC 偏移（含夏令时），但容易出错的关键点有：
- 传入
System.currentTimeMillis()是安全的；若传入一个“未来日期”但 JVM tzdata 版本老旧，可能用错 DST 规则（例如欧盟 2024 年后暂停夏令时切换尚未同步进旧 JDK） - 使用
Calendar配合TimeZone时，必须先调用calendar.setTimeZone(tz)，否则get(Calendar.ZONE_OFFSET)仍返回默认时区偏移 - 注意单位：返回值是毫秒，不是小时；
offset / (1000 * 60 * 60)才是小时数
和 java.time.ZoneId 混用会有什么后果
二者可互相转换，但语义不同，混用易引发隐性 bug：
立即学习“Java免费学习笔记（深入）”；
-
TimeZone.getTimeZone("America/New_York").toZoneId()→ 正确，生成标准ZoneId -
ZoneId.of("GMT+5").normalized()→ 得到ZoneOffset.UTC.plusHours(5)，即固定偏移，无 DST - 若将
TimeZone.getTimeZone("GMT+5")（固定偏移）转成ZoneId，再用ZonedDateTime.withLaterOffsetAtOverlap()处理春秋季重叠时间，结果不可靠 —— 它根本没定义 DST 行为
真正该怎么做
除非维护遗留代码，否则应避开 TimeZone 直接操作：
- 用
ZoneId.systemDefault()替代TimeZone.getDefault() - 用
Instant.atZone(ZoneId)或ZonedDateTime.of(..., ZoneId)替代Calendar.setTimeZone() - 时区 ID 字符串统一用 IANA 格式（如
"Europe/London"），禁用"CET"、"PST"等缩写（歧义且不支持 DST 切换） - JDK 17+ 用户注意：tzdata 更新需手动执行
jlink --bind-services --add-modules java.base --output myjre --compress=2 --no-header-files --no-man-pages并替换lib/tzdb.dat，否则ZoneId也可能滞后
最常被忽略的一点：JVM 启动后，TimeZone.getDefault() 不会响应操作系统时区变更 —— 如果你的服务长期运行且依赖系统时区，必须主动监听或定期重载，而不是假设它会自动刷新。
