Java处理夏令时应使用java.time体系，优先选ZoneId（如"America/New_York"）而非固定偏移或缩写；解析本地时间需结合时区用ZonedDateTime或LocalDateTime.atZone()；计算用ZonedDateTime或Instant；存储统一用Instant或ISO-8601 UTC格式。
Java 处理夏令时（DST）切换的关键在于避免使用过时的 Date 和 Calendar 类，改用 java.time 体系，并正确选择时区类型（如 ZoneId 而非固定偏移）。夏令时带来的“时间跳变”（如凌晨2点直接跳到3点，或回拨到1点）会导致重复/跳过小时、解析歧义、计算偏差等问题——这些不是“误差”，而是 DST 规则本身的体现，Java 的现代 API 已内置支持，只需用对方式。
用 ZoneId 替代 TimeZone 或固定偏移
固定偏移（如 ZoneOffset.of("-05:00")）完全忽略 DST；老式 TimeZone.getTimeZone("EST") 可能返回不带 DST 行为的静态时区。应始终使用带完整规则的 ZoneId，例如：
-
ZoneId.of("America/New_York")—— 自动识别 EST/EDT 切换 -
ZoneId.of("Europe/London")—— 正确处理 GMT/BST - 避免
"EST"、"PST"等缩写（模糊且不支持 DST）
解析本地时间要明确上下文：用 ZonedDateTime 或 LocalDateTime.atZone()
当输入一个“2024-03-10T02:30”这种可能处于 DST 跳变窗口的时间字符串时，LocalDateTime 本身不含时区信息，无法判断它属于标准时间还是夏令时。必须结合时区解析：
- 推荐：
ZonedDateTime.parse("2024-03-10T02:30-05:00[America/New_York]")（带时区 ID，无歧义） - 若只有本地时间字符串（如
"2024-03-10 02:30"），用LocalDateTime.parse(...).atZone(ZoneId.of("America/New_York"))—— Java 会按规则自动处理：- 在“春进”日（如 2024-03-10），
02:30不存在 → 默认抛出DateTimeException - 在“秋退”日（如 2024-11-03），
02:30出现两次 → 默认取 DST 结束后的标准时间（即 EDT → EST 后的第一次），可通过withLaterOffsetAtOverlap()或withEarlierOffsetAtOverlap()显式控制
- 在“春进”日（如 2024-03-10），
计算时间差、加减小时时，优先用 ZonedDateTime 或 Instant
直接对 LocalDateTime 加 1 小时，可能跨过 DST 边界却忽略偏移变化，导致实际间隔不准。正确做法：
立即学习“Java免费学习笔记（深入）”；
- 跨时区运算 → 用
ZonedDateTime：加 1 小时后自动适配新偏移（如从 EDT -04 → EST -05） - 纯时间跨度（如“72 小时后”）→ 转成
Instant计算（UTC 时间线无 DST）：zdt.toInstant().plus(Duration.ofHours(72)).atZone(ZoneId.of("America/New_York")) - 避免用
Calendar.add(Calendar.HOUR, 1)—— 它在 DST 边界行为不可靠，且依赖系统默认时区
存储和传输统一用 Instant 或 ISO-8601 UTC 字符串
数据库字段、API 响应、日志时间等应尽量存为 Instant（毫秒级 UTC）或其 ISO 格式（如 "2024-03-10T07:30:00Z"）。这样彻底规避 DST 解析问题。仅在展示给用户时，才用 zdt.withZoneSameInstant(userZone) 转为本地时间。
不复杂但容易忽略
