ZonedDateTime跨时区转换核心是保持瞬时时刻不变，应使用ZoneId（如"Europe/London"）而非ZoneOffset，通过withZoneSameInstant()实现准确转换，并用完整时区ID解析输出以规避夏令时与缩写歧义。

用 ZonedDateTime 做跨时区转换，关键不是“换数字”，而是“保瞬间”——同一物理时刻，在不同时区的表达自然不同，夏令时变化也由系统自动适配。

别用固定偏移，要用地理时区ID

ZoneOffset（如 "+08:00"）是死的，它永远+8小时，不管夏令时；ZoneId（如 "Asia/Shanghai"）是活的，内置完整规则库，能识别2026年5月9日伦敦正在实行夏令时（UTC+1），而12月会退回UTC+0。

• ✅ 推荐：ZonedDateTime.now(ZoneId.of("Europe/London"))
• ❌ 避免：ZonedDateTime.now(ZoneOffset.ofHours(1)) —— 这不是伦敦，只是“某个+1的地方”
• ⚠️ 注意：ZoneId.of("GMT+1") 是固定偏移写法，不推荐；必须用 "Europe/London" 才能响应DST

转换必须用 withZoneSameInstant()

这个方法名就说明一切：保持 instant（时间戳）不变，只换时区视角。比如北京时间 2026-05-09T12:37+08:00，转纽约时间不是简单减12小时，而是查纽约当前规则——5月处于EDT（UTC-4），结果是 2026-05-09T00:37-04:00。

• 调用示例：zdt.withZoneSameInstant(ZoneId.of("America/New_York"))
• 绝对不用 withZoneSameLocal()：它强行保留“12:37”这个数字，会导致时间点漂移，逻辑错误
• 转换后可直接比较 isBefore()/isAfter()，因为底层 Instant 一致

解析和输出要带真实时区标识

字符串里只写 "+08:00" 或 "CST" 是危险的：前者没地理上下文，后者歧义（China Standard Time？Central Standard Time？）。标准做法是用完整 ZoneId 包裹。

• ✅ 安全解析："2026-05-09T12:37:00.123+08:00[Asia/Shanghai]"
• ✅ 推荐格式化：DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS VV") → 输出含 "Asia/Shanghai"
• ⚠️ 避免仅依赖缩写：PST、EST、BST 等在不同国家含义不同，不可靠

警惕夏令时边界场景

每年春秋季切换日存在“跳过”或“重复”小时（如欧洲3月最后一个周日凌晨2:00直接跳到3:00）。ZonedDateTime 能感知这类异常，但需主动处理：

• 遇到“不存在的时间”（如 Berlin 2026-03-29T02:30），默认抛 DateTimeException
• 可用 withEarlierOffsetAtOverlap() 或 withLaterOffsetAtOverlap() 显式选偏移
• 从用户输入构建 ZonedDateTime 时，务必确认原始时区 ID 正确，否则整个链条失准