Java 时区与时间处理——被坑了多少次了，用 LocalDateTime 还是 ZonedDateTime
Java 时区与时间处理——被坑了多少次了，用 LocalDateTime 还是 ZonedDateTime
适读人群：有多时区业务或被时间 bug 坑过的 Java 开发者 | 阅读时长：约 14 分钟 | 核心价值：彻底搞清楚 LocalDateTime、ZonedDateTime、Instant 的使用场景，以及时区问题的系统性解决方案
我被时区问题坑了三次。
第一次：服务部署到海外，日志里的时间和业务报表对不上，因为服务器是 UTC，数据库是 UTC+8，代码里用的是 new Date()，展示时没有时区转换。
第二次：做了一个定时任务，每天凌晨 2 点执行。夏令时的那天，凌晨 2 点"不存在"（时钟从 1:59:59 直接跳到 3:00:00），任务静默失败，没有任何异常。
第三次：接口返回的时间字符串是 2023-08-15 14:30:00，没有时区信息，前端不知道是什么时区，用本地时区解释，结果用户在不同时区看到的时间不一样。
三次之后，我认真学了 Java 8 的时间 API。这篇文章是我的学习总结。
先搞清楚三个核心类的语义
Instant：时间线上的一个点
Instant 表示的是"绝对时间"，即 UTC 时间线上的一个具体时刻，不附带任何时区信息。
Instant now = Instant.now(); // 当前时刻，与时区无关
System.out.println(now); // 2024-03-15T09:23:14.847Z ← 以 UTC 表示LocalDateTime：本地日期时间，没有时区
LocalDateTime 是一个"日历上的时间点"，但不说是哪个时区的日历。2024-03-15 17:23:14 不代表任何特定的全球时刻，它在不同时区是不同的时刻。
ZonedDateTime：带时区的日期时间
ZonedDateTime = LocalDateTime + 时区。它表示完整的、明确的一个时刻。
我的使用决策规则
规则一：存储和传输用 Instant 或 UTC 时间戳
数据库里存时间，用 UTC 时间戳（bigint 存毫秒数，或者 datetime 字段配合 UTC 时区）。API 传输时用 ISO 8601 带时区的字符串。
package com.example.time;
import java.time.*;
import java.time.format.DateTimeFormatter;
/**
* 时间处理工具类——统一用 UTC 存储和传输
*/
public class TimeUtils {
// 标准 ISO 8601 格式，带时区偏移
public static final DateTimeFormatter ISO_FORMATTER =
DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ssXXX");
/**
* 获取当前 UTC 时间戳（毫秒）
* 存数据库推荐用这个
*/
public static long nowEpochMilli() {
return Instant.now().toEpochMilli();
}
/**
* 格式化为带时区的 ISO 8601 字符串
* API 返回时间给客户端，必须带时区信息
*/
public static String formatWithTimezone(Instant instant, ZoneId zoneId) {
return ZonedDateTime.ofInstant(instant, zoneId).format(ISO_FORMATTER);
// 返回类似：2024-03-15T17:23:14+08:00
}
/**
* 解析带时区的字符串
*/
public static Instant parseWithTimezone(String datetimeString) {
return ZonedDateTime.parse(datetimeString, ISO_FORMATTER).toInstant();
}
}规则二：业务计算用 ZonedDateTime
涉及时区的业务逻辑（比如"用户当地时间每天 9 点"），必须用 ZonedDateTime，不能用 LocalDateTime。
package com.example.time;
import java.time.*;
/**
* 跨时区的业务逻辑示例
*/
public class TimezoneBusinessExample {
/**
* 计算指定时区下的"今天结束时间"
* 比如：北京时间今天 23:59:59
*/
public static Instant getEndOfDayInTimezone(ZoneId userTimezone) {
return LocalDate.now(userTimezone)
.atTime(LocalTime.MAX) // 23:59:59.999999999
.atZone(userTimezone) // 附加时区信息
.toInstant(); // 转为 Instant（UTC 时刻）
}
/**
* 判断用户所在时区是否是工作时间（9:00 - 18:00）
*/
public static boolean isWorkingHours(ZoneId userTimezone) {
ZonedDateTime now = ZonedDateTime.now(userTimezone);
int hour = now.getHour();
return hour >= 9 && hour < 18;
}
}规则三：LocalDateTime 用在没有时区歧义的场景
比如：系统日志时间（服务器时区固定）、不跨时区的本地应用、纯粹的日期计算（几天后）。
// LocalDateTime 适合：
LocalDateTime threeMonthsLater = LocalDate.now().plusMonths(3).atStartOfDay();
// "三个月后的今天"，不需要时区踩坑实录一：new Date() 在多时区环境输出混乱
旧代码里还有大量 java.util.Date 和 java.util.Calendar，这些类的设计非常糟糕：
Date.toString()使用 JVM 系统时区格式化，同一个 Date 对象，在不同时区的服务器上toString()输出不同Calendar.getInstance()默认用系统时区
迁移策略：
package com.example.time;
import java.util.Date;
import java.time.Instant;
import java.time.ZoneId;
import java.time.ZonedDateTime;
/**
* 从旧的 java.util.Date 迁移到 java.time 的转换工具
*/
public class DateMigrationUtils {
// 旧 Date -> Instant
public static Instant toInstant(Date legacyDate) {
return legacyDate.toInstant();
}
// 旧 Date -> ZonedDateTime
public static ZonedDateTime toZonedDateTime(Date legacyDate, ZoneId zoneId) {
return legacyDate.toInstant().atZone(zoneId);
}
// Instant -> 旧 Date（不得不用旧 API 时）
public static Date fromInstant(Instant instant) {
return Date.from(instant);
}
}踩坑实录二：数据库 datetime 字段和 Java 时间的时区问题
这是线上问题频率最高的时区坑。
MySQL 的 datetime 类型不存储时区信息，存进去什么就取出来什么。如果你 JVM 时区是 UTC，数据库时区是 Asia/Shanghai，写入和读出会差 8 小时。
配置 JDBC URL 时，要明确指定时区：
jdbc:mysql://host:3306/db?serverTimezone=Asia/Shanghai&useSSL=false更可靠的做法是：
package com.example.time;
import java.time.*;
/**
* 数据库时间处理的最佳实践：
* 1. 用 timestamp 而不是 datetime（timestamp 存 UTC 时间戳，不受时区影响）
* 2. 或者用 LocalDateTime 映射，明确约定所有时间都是 UTC
*/
public class DbTimeConvention {
// 约定：数据库存的所有时间都是 UTC
private static final ZoneId DB_TIMEZONE = ZoneId.of("UTC");
// 读出的 LocalDateTime（来自数据库）转成带时区的 ZonedDateTime
public static ZonedDateTime fromDb(LocalDateTime dbValue) {
return dbValue.atZone(DB_TIMEZONE);
}
// 存入数据库前，把 ZonedDateTime 转成 UTC 的 LocalDateTime
public static LocalDateTime toDb(ZonedDateTime value) {
return value.withZoneSameInstant(DB_TIMEZONE).toLocalDateTime();
}
}踩坑实录三：夏令时导致的坑
我提到的定时任务在夏令时出问题，就是因为用了错误的方式计算"下次执行时间"。
// 错误：用 LocalDateTime 加 1 天，夏令时当天会差 1 小时
LocalDateTime nextRun = LocalDateTime.now().plusDays(1);
// 夏令时时钟跳跃时，"明天同一时间"在 UTC 时间上可能相差 23 小时或 25 小时
// 正确：用 ZonedDateTime，它处理了夏令时
ZonedDateTime nextRun = ZonedDateTime.now(ZoneId.of("America/New_York")).plusDays(1);
// plusDays 是日历上的 +1 天，会自动处理夏令时如果你的服务不涉及美国、欧洲等有夏令时的地区，这个问题可以忽略。但如果有，必须用 ZonedDateTime 做时间计算。
常见时区 ZoneId 的正确写法
// 正确写法：用 IANA 时区名称
ZoneId beijing = ZoneId.of("Asia/Shanghai"); // 北京/上海时间
ZoneId newYork = ZoneId.of("America/New_York");
ZoneId utc = ZoneId.of("UTC");
ZoneId london = ZoneId.of("Europe/London");
// 错误写法：用简写（有歧义，不推荐）
ZoneId.of("CST"); // CST 可以是 China Standard Time，也可以是 Central Standard Time（美国）
ZoneId.of("EST"); // 有歧义
// 获取 JVM 默认时区（谨慎使用）
ZoneId systemDefault = ZoneId.systemDefault();
// 不推荐在业务代码里用这个，因为它随 JVM 配置变化而变化我的推荐：生产环境把 JVM 时区固定设成 UTC，避免任何"默认时区"带来的不确定性：
-Duser.timezone=UTC然后在应用层明确处理时区转换，不依赖 JVM 默认时区。