zoneddatetime是跨国电商处理时区最可靠方案，绑定地理时区规则，自动适配夏令时、历史变更与边界异常；必须用zoneid（如"asia/shanghai"）而非固定偏移；跨时区转换用withzonesameinstant()保持瞬时一致；解析存储需含完整时区id，推荐instant或vv格式字符串。
ZonedDateTime 是跨国电商系统处理时区问题最可靠的选择——它不靠人工算偏移，而是绑定真实地理时区规则，自动适配夏令时切换、历史时区变更和边界异常时间。
用 ZoneId 替代固定偏移，避免夏令时失准
电商订单时间、库存释放、促销倒计时等关键逻辑，必须基于真实时区规则。固定偏移（如 ZoneOffset.of("+08")）无法响应 DST 变化，也不代表任何具体地区。
- ✅ 正确：用 ZoneId.of("Asia/Shanghai") 表示中国标准时间（全年 UTC+8，无夏令时）
- ✅ 正确：用 ZoneId.of("Europe/Paris") 表示巴黎时间（冬令时 UTC+1，夏令时 UTC+2）
- ❌ 错误：用 ZoneOffset.ofHours(1) 或 ZoneId.of("GMT+1") —— 这只是静态偏移，不是巴黎
跨时区转换只用 withZoneSameInstant()
用户下单时间（如柏林当地时间）、仓库发货时间（如上海）、物流跟踪时间（如纽约）需指向同一物理时刻。转换本质是“换视角”，不是“改数字”。
- 调用 zdt.withZoneSameInstant(ZoneId.of("America/Chicago"))，底层 Instant 不变，仅重算本地时间和当前偏移
- 例如：2026年6月8日 14:00 柏林时间（CEST, UTC+2）→ 芝加哥时间为当日 07:00（CDT, UTC-5），差值自动为 7 小时
- ⚠️ 绝对不用 withZoneSameLocal()：它强行保留“14:00”，会把时间点错位一小时甚至更多
解析与存储必须带完整时区 ID
前端传参、API 请求、数据库字段若只含偏移（如 "2026-06-08T14:00:00+02:00"）或缩写（如 "PST"），ZonedDateTime 无法还原真实地理上下文，极易歧义。
- ✅ 安全解析格式："2026-06-08T14:00:00.123+02:00[Europe/Berlin]"
- ✅ 存储推荐：Instant（UTC 时间戳）或带 VV 格式的字符串（如 "2026-06-08 14:00:00.123 Europe/Berlin"）
- ✅ 输出给前端或日志：用 DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS VV")
- ❌ 避免仅存 "+02:00" 或 "CET"：前者无地理含义，后者在不同年份可能指标准时或夏令时
订单生命周期中的典型场景处理
电商系统中，时间贯穿下单、支付、履约、售后全流程，每个环节都需明确时区归属。
- 用户提交时间：用其浏览器或设备上报的 ZoneId 构建 ZonedDateTime（如 LocalDateTime.parse(...).atZone(userZone)）
- 统一存储：立即转为 Instant 或 UTC ZonedDateTime，避免本地时区污染
- 履约调度：仓库按本地时区（如 Asia/Shanghai）排班，用 zdt.withZoneSameInstant(warehouseZone) 对齐物理时刻
- 超时判断：比较两个 ZonedDateTime 前，先转成 Instant 再比纳秒值，不依赖 .equals()
