一、Java时间处理的演进:从混乱到清晰
旧API的缺陷
-
java.util.Date:设计粗糙,年份从1900开始,月份从0计数,线程不安全java.util.Calendar:操作繁琐,时区处理易出错,代码可读性差
// 旧API创建日期(不推荐)
Date date = new Date(124, 7, 19); // 2024年8月19日?实际是2024-08-19
- Java 8的救赎
JSR 310引入java.time包,基于ISO-8601标准,提供不可变、线程安全的类:
-
LocalDate:纯日期(2024-08-19)LocalTime:纯时间(14:30:00)LocalDateTime:日期+时间(2024-08-19T14:30)ZonedDateTime:带时区的完整时间(2024-08-19T14:30+08:00[Asia/Shanghai])
二、时区处理:避坑核心战场
关键认知:所有时间存储与计算应基于UTC,显示时再转换为本地时区。
// 时区转换示例
ZonedDateTime shanghaiTime = ZonedDateTime.now(ZoneId.of("Asia/Shanghai"));
ZonedDateTime newYorkTime = shanghaiTime.withZoneSameInstant(ZoneId.of("America/New_York"));
System.out.println("上海: " + shanghaiTime); // 上海: 2024-08-19T15:30+08:00[Asia/Shanghai]
System.out.println("纽约: " + newYorkTime); // 纽约: 2024-08-19T03:30-04:00[America/New_York]
三、高频操作实战示例
日期计算
LocalDate today = LocalDate.now();
LocalDate nextWeek = today.plusWeeks(1);
Period period = Period.between(today, nextWeek); // 计算日期间隔
格式化与解析
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm");
String formatted = LocalDateTime.now().format(formatter); // 2024/08/19 15:45
LocalDateTime parsed = LocalDateTime.parse("2024/08/20 09:00", formatter);
时间点转换
Instant instant = Instant.now(); // 当前UTC时间戳
ZonedDateTime londonTime = instant.atZone(ZoneId.of("Europe/London"));
四、新旧API迁移策略
兼容转换
// Date → Instant
Instant instant = new Date().toInstant();
// Calendar → ZonedDateTime
ZonedDateTime zdt = ZonedDateTime.ofInstant(calendar.toInstant(), calendar.getTimeZone().toZoneId());
禁用模式
⚠️ 避免在新代码中使用:
new java.util.Date() // 改用Instant
SimpleDateFormat // 改用DateTimeFormatter
关键结论:始终优先使用java.time API,其明确的类型设计(如LocalDate与ZonedDateTime分离)能从根本上避免80%的时间处理错误。对于遗留系统,通过Instant进行新旧API桥接是最安全的迁移路径。
596

被折叠的 条评论
为什么被折叠?



