Java使用Calendar.add计算时间偏移后返回时间戳与预期相差1小时

出现整整1小时的偏差，和时间加减的逻辑本身无关，本质是两端采用的时区规则不匹配：

• 你输入的原始日期字符串已经携带了+0300的时区偏移，明确声明这个时间是按UTC+3规则定义的；你换算预期时间戳时，也是严格按照固定UTC+3的规则得到的结果。
• 但你代码里初始化GregorianCalendar和SimpleDateFormat时都没有指定时区，默认绑定了JVM加载的动态时区规则（比如Europe/Moscow这类会随当地政策调整的时区）。这类动态时区的规则记录显示：2011年到2014年期间俄罗斯曾永久取消冬令时，莫斯科当时实际采用的是UTC+4的偏移，和你输入的+0300固定偏移刚好差1小时。
• 这就导致代码在解析、计算时间字段的时候，自动套用了UTC+4的时区规则，最终算出的时间戳自然比固定UTC+3下的预期值多了整整1小时。
• 另外有个测试细节的小问题：你取的预期值1328072399000是整秒级的时间戳，但你解析的源字符串是带.999毫秒精度的，哪怕时区规则完全对齐，正确结果也应该是带999毫秒的数值，你的测试预期本身漏了这部分精度。

老版本JDK（Java 7及以下）的临时修复 #

修改方法逻辑，给时间格式化组件和日历对象都显式绑定固定的UTC+3偏移，不依赖系统自带的动态时区规则：

public static long addHoursToDate(String dateStr, int hours) throws ParseException {
    // 显式指定固定UTC+3时区，不跟随系统动态时区配置
    TimeZone fixedUtcPlus3 = TimeZone.getTimeZone("GMT+03:00");
    SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSSZ");
    simpleDateFormat.setTimeZone(fixedUtcPlus3);
    Date date = simpleDateFormat.parse(dateStr);
    Calendar result = new GregorianCalendar(fixedUtcPlus3);
    result.setTime(date);
    result.add(Calendar.HOUR, hours);
    return result.getTimeInMillis();
}

推荐的根治方案（Java 8及以上） #

直接替换老旧的Date/Calendar/SimpleDateFormat实现，使用内置的java.time系列类处理时间，从根源上避开动态时区规则的兼容问题：

public static long addHoursToDate(String dateStr, int hours) {
    // 自动解析字符串中携带的+0300偏移量，不依赖外部动态时区规则
    OffsetDateTime sourceTime = OffsetDateTime.parse(
            dateStr,
            DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSSZ")
    );
    // 直接基于绝对时间轴做小时偏移，不受当地时区政策变动影响
    return sourceTime.plusHours(hours).toInstant().toEpochMilli();
}

注意：修复后方法返回的实际时间戳为1328072399999，需要同步把测试用例的预期值从整秒的1328072399000调整为匹配源字符串毫秒精度的正确值，才能通过校验。

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