DateTimeFormatter.withZone跨时区格式化时年份计算异常

核心诱因：格式化占位符语义错配 #

该现象并非JDK时区逻辑缺陷，也不是时间计算错误，本质是混淆了DateTimeFormatter中两个年份类占位符的适用场景与计算规则：

• yyyy：对应自然公历年，即日常认知里1月1日到12月31日的公元纪年，和日期实际所属的自然年完全匹配
• YYYY：对应ISO 8601 周制周年，仅适用于按周做统计、年度归属的专业场景，并非通用自然年标识

ISO周制年的计算规则 #

ISO体系下的周制年判定逻辑为：

• 一周以周一为起点、周日为终点
• 每个自然年的第一周，是包含该年第一个周四的完整周
• 只要日期落在某一周制年的周覆盖范围内，即使该日期在公历上属于上一年12月或下一年1月，也会被归入对应周制年的计算范围

对应本次测试场景，纽约时区2021-01-01 00:00 换算为芝加哥本地时间是2020-12-31 23:00（周四）。按照ISO规则，2021年的第一个周四就是1月1日，包含该周四的完整周覆盖范围为2020-12-28（周一）至2021-01-03（周日），整周都会被归为2021年的周制年。这就是单独用YYYY格式化芝加哥时区时间时，输出固定为2021的直接原因。

对“月、日计算正确”的认知纠偏 #

之前判定“除年份外所有日期字段都符合时区换算预期”，本质是对输出结果的语义误解：

• 月、日字段的时区换算确实是准确的：芝加哥本地时间确实是12月31日
• 但拼接出来的2021-12-31并不等于“2021年12月31日”的自然年语义——它只是“周制年2021框架下的12月31日”，和真实的自然年日期已经产生偏移。只是月、日数值刚好和换算结果匹配，才会让人误以为只有年份算错。

修正方案 #

如果需要输出日常通用的自然年日期，只需将格式化模式中所有大写YYYY替换为小写yyyy即可。比如原模式"YYYY-MM-dd"调整为"yyyy-MM-dd"后：

• 芝加哥时区格式化该时间点，会正确输出2020-12-31
• 单独格式化年份字段，会正确输出2020
  完全匹配时区换算的实际结果。

预期合理性判断 #

“芝加哥时区该时间点应显示2020年”的判断不存在认知偏差：纽约时区2021年1月1日零点，对应西六区的芝加哥确实是2020年12月31日23点，本地自然年归属为2020，这个时间换算的逻辑完全正确。所有异常表现均来自格式化占位符的语义错用，和时区逻辑、JDK实现无关。

内容的提问来源于stack exchange，提问作者dfrugg