Calendar.add时区异常及时长计算偏差问题咨询

1. 为什么Calendar.add方法看起来会更改时区？ #

其实Calendar.add()本身并不会主动修改Calendar实例的时区属性，但它的行为完全依赖于当前Calendar绑定的时区规则来调整日期字段，这很容易让你产生“时区变了”的误解，常见原因有这几个：

• 夏令时切换的隐性影响：如果调整的日期恰好跨越了时区的夏令时（DST）切换点，Calendar会自动根据时区规则调整时间偏移量。比如用IST时区时，若某年夏令时生效，时钟被拨快1小时，调用add()调整日期后，输出的时间字符串可能会显示不同的偏移标识（比如从+05:30变成+06:30），但实际上Calendar的时区还是IST，只是偏移量随夏令时规则变化了。
• 时区规则的差异化计算：Calendar的字段调整是基于时区的日历规则，比如不同时区的月份天数、闰年规则略有差异。当你跨月或跨年调整时，计算出的最终时间在不同时区的展示结果不同，但这不是时区被修改了，而是同一时间在不同时区的表示形式不同。
• 格式化工具的误用：如果你用了默认时区的SimpleDateFormat来格式化Calendar的时间，而不是Calendar实例本身的时区，就会出现时间显示和预期时区不符的情况，误以为是add()改了时区。

2. IST时区下时长略少于35天取整为34天的原因 #

你的逻辑里，当range >=30时durationInDays = range-1，但实际调试时因为IST时区导致时长略少于35天取整为34，核心问题出在**「日历天数」和「绝对时间天数」的差异**，以及IST时区的夏令时规则：

• Calendar.add是按日历天数调整：当你调用calendar.add(Calendar.DAY_OF_MONTH, 35)，它是按日历上的“天数”累加的——比如从3月1号加35天直接跳到4月5号，完全遵循日历规则，不管这35天里有没有夏令时切换。但这个操作对应的绝对时间跨度（毫秒数）不一定是精确的35 * 86400000（即35个完整的24小时）。
• IST时区的夏令时导致单日时长变化：印度部分年份会实行夏令时，在切换当天，一天的时长会变成23小时（拨快1小时）或25小时（拨慢1小时）。如果你的时间范围恰好包含了这样的切换日，35个日历天对应的绝对时间就会比35*24小时少1小时（总毫秒数少3600000）。
• 取整逻辑放大了差异：如果你的durationInDays是通过计算两个时间的毫秒差除以86400000得到的，那么(35*86400000 - 3600000) / 86400000 = 34.958333...，要是用int强制转换或者向下取整，结果就会是34，这就是你看到的现象。

如果想避免这类问题，建议改用Java 8及以上的java.time包（比如LocalDate、Period类），这些类要么是时区无关的日期计算，要么能更精准地处理时区规则，不会出现这种因为夏令时导致的天数计算偏差。

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