Java现代日期API自动处理夏令时，需用ZonedDateTime等带时区类型而非LocalDateTime；解析或获取时间时立即绑定ZoneId；跨天计算优先用Instant或ZonedDateTime.plusDays()。
Java 的现代日期时间 API（java.time 包）在处理夏令时（DST）切换时，是**自动感知并正确应用时区规则**的，不需要手动调整偏移量。关键在于：始终使用带时区信息的类型（如 ZonedDateTime 或 OffsetDateTime），避免用纯 LocalDateTime 表示带时区含义的时间。
用 ZonedDateTime 代替 LocalDateTime 处理本地时间上下文
LocalDateTime 没有时区或偏移概念，它只是“日历+钟表”，无法表达“2024年3月10日凌晨2点在美国东部是 EST 还是 EDT”。一旦涉及夏令时切换（如春进秋退），直接用它解析或计算会出错。
正确做法是：从字符串或系统时间出发，立刻绑定到具体时区：
- 解析带时区缩写或 ID 的字符串：
ZonedDateTime.parse("2024-03-10T02:30-05:00", DateTimeFormatter.ISO_OFFSET_DATE_TIME)或ZonedDateTime.parse("2024-03-10T02:30:00[America/New_York]") - 获取当前时刻的带时区时间：
ZonedDateTime.now(ZoneId.of("Europe/London")) - 转换时区时保持语义正确：
zdt.withZoneSameInstant(ZoneId.of("America/Chicago"))—— 瞬间不变，仅显示形式变
理解“重复时间”和“跳过时间”的自动处理
夏令时切换会导致两种特殊情况：
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
秋退（DST end）：如美国东部时间 2024年11月3日 凌晨2:00 回拨到 1:00，出现两个 1:30（EST 和 EDT）。
ZonedDateTime会按标准规则选择（通常默认取后一个，即 EST），也可用withLaterOffsetAtOverlap()或withEarlierOffsetAtOverlap()显式控制 -
春进（DST start）：如 2024年3月10日 凌晨2:00 直接跳到 3:00，2:00–2:59 不存在。若尝试构造该范围内的
ZonedDateTime，会自动“跳过”并取下一个有效时间（如 3:00）
避免手动操作偏移量（ZoneOffset）
不要用 ZoneOffset.of("-04:00") 替代 ZoneId.of("America/New_York")。前者是固定偏移，不随 DST 变化；后者是动态时区规则，能查 IANA 时区数据库，自动识别 2024 年 3–11 月用 -04:00（EDT），其余月份用 -05:00（EST）。
常见错误示例：
- ❌
OffsetDateTime.now(ZoneOffset.of("-04:00"))—— 全年都用 -04:00，忽略实际 DST 规则 - ✅
ZonedDateTime.now(ZoneId.of("America/New_York"))—— 自动返回当前生效的偏移（EDT 或 EST）
跨天计算要基于瞬时（Instant），而非本地时间
做“7天后”、“上个月”这类运算时，若用 LocalDateTime.plusDays(7) 再转时区，可能因夏令时切换导致结果偏差（例如在切换日附近加减一天，实际跨越了23或25小时）。
更可靠的方式是：
- 先转成
Instant（UTC 瞬间，无歧义） - 在 Instant 上做加减（
instant.plus(7, ChronoUnit.DAYS)） - 再转回目标时区的
ZonedDateTime
或者直接对 ZonedDateTime 调用 plusDays(7) —— 它内部已按“同一时区下的日历日”语义处理，并自动适配 DST 边界。
