calendar的settimezone仅改变时区解释视角，不修改内部毫秒值；真正时区转换需用gettimeinmillis()获取utc时间戳，再用新时区重建calendar，或改用java.time的zoneddatetime.withzonesameinstant()。
Calendar 的 setTimeZone 方法不会改变已设置的日期时间值，只影响后续的 getTime()、get() 等操作对时区的解释方式。
setTimeZone 的作用是“重新解释”而非“转换时间”
Calendar 内部以毫秒数（自 1970-01-01 00:00:00 UTC 起）存储时间。调用 setTimeZone(TimeZone tz) 只是告诉 Calendar：今后读取或格式化这个毫秒值时，按新时区来理解——它不修改底层毫秒值，也不自动做时区换算。
- 比如一个 Calendar 原本设为 “2024-06-01 12:00:00 GMT+8”，内部毫秒值对应 UTC 时间 2024-06-01 04:00:00
- 执行 setTimeZone(TimeZone.getTimeZone("GMT+0")) 后，再调用 get(Calendar.HOUR_OF_DAY) 会返回 4（UTC 时间的小时），而不是 12
- getTime() 返回的 Date 对象本身不含时区信息，但 toString() 输出会按当前 Calendar 的时区显示
想真正“转换时间”到另一个时区，得先获取 UTC 毫秒，再用新时区重建 Calendar
如果目标是把“北京时间 12 点”变成“伦敦时间 4 点”（即同一时刻在另一时区的表示），不能只靠 setTimeZone，而应：
- 用 cal.getTimeInMillis() 获取原始毫秒值（本质是 UTC 时间戳）
- 新建一个 Calendar 实例：Calendar newCal = Calendar.getInstance(TimeZone.getTimeZone("GMT+0"))
- 调用 newCal.setTimeInMillis(originalMillis)
- 此时 newCal.get(Calendar.HOUR_OF_DAY) 就是 4
常见误区：setTimeZone 后直接 get() 得到的不是“换算后的时间”
很多开发者误以为 setTimeZone 会像“调整钟表”一样把时间数字改掉。实际上它只是切换了“读表视角”。例如：
- Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("Asia/Shanghai"));
- cal.set(2024, Calendar.JUNE, 1, 12, 0, 0); // 设为北京时间 6 月 1 日 12:00
- cal.setTimeZone(TimeZone.getTimeZone("America/New_York"));
- System.out.println(cal.get(Calendar.HOUR_OF_DAY)); // 输出 0（因为 UTC 是 4:00，纽约是 UTC-4，所以是 0 点）
注意：这不是“把 12 点改成 0 点”，而是“同一个 UTC 时刻（04:00）在纽约本地是 0 点”。
推荐更清晰的做法：用 java.time 替代 Calendar
Calendar 的时区逻辑容易混淆。Java 8+ 推荐用 java.time API：
- ZonedDateTime zdt = ZonedDateTime.of(2024, 6, 1, 12, 0, 0, 0, ZoneId.of("Asia/Shanghai"));
- ZonedDateTime inNY = zdt.withZoneSameInstant(ZoneId.of("America/New_York"));
- System.out.println(inNY); // 直接输出 2024-06-01T00:00-04:00[America/New_York]
语义明确：“same instant” 表示同一时刻，“withZone” 才是真正的时区转换。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
