3个代码搞定加州时差计算，附完整示例
学会语法却不知怎么搭项目？别急，今天直接上硬菜。很多应届生背熟了 Python 或 Java 的日期类，一到实战处理跨时区业务就懵圈，尤其是像【加州时差】这种涉及夏令时（DST）切换的复杂场景。光看文档不够，必须手敲一遍【完整示例】，才能把 ZoneId、OffsetDateTime 和数据库存储的坑填平。
这篇文章不玩虚的，我们从一个真实的“全球协作日历提醒系统”切入，手把手带你从零搭建一个能正确处理美西时间的后端模块。你会看到目录怎么建、代码怎么拆、测试怎么写，以及如何在生产环境避免“时间漂移”。
项目目标与业务场景
我们要解决的问题很具体：一个 SaaS 平台允许用户设置提醒，但服务器部署在 UTC 时区，用户分布在旧金山、纽约和北京。当用户在旧金山（太平洋时间 PT）设置“明天上午 9 点提醒我开会”，系统必须准确计算出 UTC 时间，并在正确的时刻触发推送。
难点在于：加州遵循太平洋时间标准，一年中会进行两次夏令时切换（3月第二个周日和11月第一个周日）。这意味着，同样的“上午9点”，在1月和7月对应的 UTC 偏移量是不同的（UTC-8 vs UTC-5）。如果只用简单的 hours + 8 硬编码，你的系统会在每年3月和11月出错，导致提醒早到或迟到3小时。
我们的目标是：准确解析：正确处理带时区信息的用户输入。
统一存储：数据库只存 UTC 时间，避免时区污染。
动态转换：根据用户所在时区，在展示层实时转换，支持夏令时自动调整。这不是玩具代码，而是生产级架构的缩影。下面我们从工程结构开始。
目录结构与工程初始化
不要把所有代码塞在一个文件里。对于涉及时间处理的模块，清晰的分层至关重要。假设我们使用 Java 17 + Spring Boot 3，因为 Java 的 java.time 包是处理时区的最佳实践之一（Python 的 zoneinfo 也类似，逻辑通用）。
项目结构如下：
src/main/java/com/example/timezone/
├── controller
│ └── ReminderController.java # 接收用户请求
├── service
│ ├── TimeZoneService.java # 核心时区转换逻辑
│ └── ReminderService.java # 业务逻辑（创建、查询提醒）
├── model
│ ├── Reminder.java # 数据模型
│ └── UserPreference.java # 用户时区偏好
├── util
│ └── TimeUtils.java # 辅助工具类
└── exception└── TimeZoneParseException.java # 自定义异常关键点：TimeZoneService 是独立的服务层，不依赖具体的数据库实现。这样我们可以轻松替换时区库（比如从 java.time 切换到 Joda-Time，虽然前者已内置，但架构上要保持解耦）。
初始化 Maven 依赖，确保使用 JDK 8+ 的 java.time，无需额外引入第三方库（除了测试用的 JUnit 5）。这是最干净的做法，因为 JDK 内置的时区数据库（TZDB）会随 JDK 更新，而手动维护时区数据是灾难的开始。
核心代码实现与逐行讲解
1. 数据模型设计
Reminder 实体只存储 UTC 时间戳，这是铁律。
import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import jakarta.persistence.Column;
import java.time.Instant;@Entity
public class Reminder {@Idprivate Long id;// 存储绝对时间点，与时区无关@Column(nullable = false)private Instant triggerTimeUtc;// 存储用户创建提醒时所在的时区 ID，如 America/Los_Angeles@Column(nullable = false)private String userTimeZoneId;// ... 其他字段
}为什么存 Instant 而不是 LocalDateTime？
LocalDateTime 没有时区信息，它只是一个“日历时间”。如果存 LocalDateTime，当用户从旧金山飞到纽约，你无法判断他指的是“旧金山的9点”还是“纽约的9点”。Instant 是绝对时间，对应地球上的某一瞬间，是唯一安全的存储格式。
2. 核心转换逻辑
这是文章的灵魂。TimeZoneService 负责处理所有的时区数学题。
import org.springframework.stereotype.Service;
import java.time.*;
import java.time.zone.ZoneRules;@Service
public class TimeZoneService {/*** 将用户输入的“当地日期时间”转换为 UTC Instant* @param localDateTime 用户看到的日期时间，如 2023-07-04T09:00* @param zoneId 用户所在时区，如 America/Los_Angeles* @return UTC 时间戳*/public Instant convertToUtc(LocalDateTime localDateTime, String zoneId) {// 1. 获取时区规则，这里会自动处理夏令时ZoneId zone = ZoneId.of(zoneId);// 2. 将 LocalDateTime 绑定到 ZoneId，得到 ZonedDateTime// 注意：ZonedDateTime 知道此时是 PDT (UTC-7) 还是 PST (UTC-8)ZonedDateTime zonedDateTime = localDateTime.atZone(zone);// 3. 转换为 Instant (UTC)return zonedDateTime.toInstant();}/*** 将 UTC Instant 转换回用户当地的 LocalDateTime (用于展示)* @param utcInstant 数据库中的 UTC 时间* @param zoneId 当前用户查看时所在的时区* @return 用户当地的日期时间*/public LocalDateTime convertToUserLocal(Instant utcInstant, String zoneId) {ZoneId zone = ZoneId.of(zoneId);return utcInstant.atZone(zone).toLocalDateTime();}
}逐行拆解：ZoneId.of(America/Los_Angeles)：这是 IANA 时区数据库的标准 ID。严禁使用 PST 或 PDT 这种缩写，因为它们不区分年份，无法正确处理历史夏令时规则。IANA ID 是唯一的、标准的、可追溯的。
localDateTime.atZone(zone)：这一步是核心。它不是简单加偏移量，而是查询 ZoneRules。在 2023 年 7 月，它会查到偏移量是 -7:00；在 2023 年 1 月，查到的是 -8:00。
RFC 规范背景：虽然 HTTP 头中的时区标识符有 RFC 822 等历史规范，但现代应用普遍遵循 IANA Time Zone Database 标准。Java 的 ZoneId 直接映射 IANA ID，保证了与操作系统、浏览器时区数据库的一致性。如果你发现前端 JS 的 Date 对象和后端 Java 的时间不一致，99% 是因为时区 ID 不匹配或 TZDB 版本落后。3. 控制器层：接收与校验
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;@RestController
@RequestMapping(/api/reminders)
public class ReminderController {private final TimeZoneService timeZoneService;private final ReminderService reminderService;// 构造函数注入public ReminderController(TimeZoneService timeZoneService, ReminderService reminderService) {this.timeZoneService = timeZoneService;this.reminderService = reminderService;}@PostMappingpublic ResponseEntityString createReminder(@RequestBody ReminderRequest request) {// 1. 解析用户传入的字符串时间，格式必须严格LocalDateTime userLocalTime = LocalDateTime.parse(request.getTime(), DateTimeFormatter.ISO_LOCAL_DATE_TIME);// 2. 获取用户声明的时区，并进行合法性校验String userZone = request.getUserTimeZone();if (!TimeZoneService.isValidZone(userZone)) {throw new IllegalArgumentException(Invalid time zone ID: + userZone);}// 3. 转换并存储reminderService.create(userLocalTime, userZone);return ResponseEntity.ok(Reminder created);}// 辅助静态方法public static boolean isValidZone(String zoneId) {try {ZoneId.of(zoneId);return true;} catch (Exception e) {return false;}}
}避坑指南：不要信任客户端时间：客户端传来的 time 字段只是“用户认为的当地时间”，我们必须结合 userTimeZone 才能还原真实时刻。
校验时区 ID：用户可能手误输入 Los_Angeles 而不是 America/Los_Angeles。ZoneId.of 会抛异常，我们要捕获并返回友好的错误信息。运行与测试：验证夏令时边界
写代码不测试，等于没写。特别是时区代码，必须覆盖夏令时切换的边界日期。
1. 单元测试用例
我们使用 JUnit 5 编写测试。重点关注 2023 年的两个切换点：开始夏令时：2023-03-12 02:00 (PST) - 03:00 (PDT)
结束夏令时：2023-11-05 02:00 (PDT) - 01:00 (PST)import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;
import java.time.*;class TimeZoneServiceTest {private final TimeZoneService service = new TimeZoneService();@Testvoid testSummerTimeConversion() {// 7月4日，加州是 PDT (UTC-7)LocalDateTime local = LocalDateTime.of(2023, 7, 4, 9, 0);String zone = America/Los_Angeles;Instant utc = service.convertToUtc(local, zone);// 期望 UTC 是 16:00 (9 + 7 = 16)ZonedDateTime expectedUtc = ZonedDateTime.ofInstant(Instant.parse(2023-07-04T16:00:00Z), ZoneOffset.UTC);assertEquals(expectedUtc.toInstant(), utc);}@Testvoid testWinterTimeConversion() {// 1月1日，加州是 PST (UTC-8)LocalDateTime local = LocalDateTime.of(2023, 1, 1, 9, 0);String zone = America/Los_Angeles;Instant utc = service.convertToUtc(local, zone);// 期望 UTC 是 17:00 (9 + 8 = 17)ZonedDateTime expectedUtc = ZonedDateTime.ofInstant(Instant.parse(2023-01-01T17:00:00Z), ZoneOffset.UTC);assertEquals(expectedUtc.toInstant(), utc);}@Testvoid testDstTransitionBoundary() {// 2023-03-12 是切换日// 02:30 PST 是不存在的（时钟从 02:00 跳到 03:00）// 这里测试一个有效的跨越点：02:59 PSTLocalDateTime local = LocalDateTime.of(2023, 3, 12, 2, 59);String zone = America/Los_Angeles;Instant utc = service.convertToUtc(local, zone);// 02:59 PST (UTC-8) = 10:59 UTCassertEquals(Instant.parse(2023-03-12T10:59:00Z), utc);// 测试 03:01 PDT (UTC-7)LocalDateTime localAfter = LocalDateTime.of(2023, 3, 12, 3, 1);Instant utcAfter = service.convertToUtc(localAfter, zone);// 03:01 PDT (UTC-7) = 10:01 UTCassertEquals(Instant.parse(2023-03-12T10:01:00Z), utcAfter);}
}观察：注意 testDstTransitionBoundary 中的时间跳变。02:59 PST 是 10:59 UTC，而 03:01 PDT 是 10:01 UTC。时间在“前进”了，但 UTC 时间倒退了？不，是时区偏移量变了。从 UTC-8 变成 UTC-7，相当于“快”了1小时。这段代码如果写成硬编码偏移量，绝对通不过测试。
2. 集成测试
模拟一个完整的 HTTP 请求，确保 Controller 和 Service 协作正常。
@Test
void testCreateReminderWithInvalidZone() {// 使用 MockMvc 发送请求// 预期返回 400 Bad Request// 验证错误消息包含 Invalid time zone ID
}优化扩展与生产环境避坑
1. 时区数据库更新问题
JDK 的时区数据库（TZDB）是静态的。如果某个国家（如智利）突然改变夏令时规则，而你的 JDK 版本较旧，你的代码会算错。
解决方案：定期升级 JDK：这是最根本的办法。
使用可更新的 TZDB：Java 9+ 允许通过 java.time.tzdb 包指定外部 TZDB 文件。在 Spring Boot 中，你可以配置 spring.jdk.timezone.database 指向一个最新版本的 TZDB 文件，实现热更新。
监控时区变更：订阅 IANA 的时区变更通知（tz-announce 邮件列表）。2. 前端与后端的时区协同
前端 JavaScript 的 Date 对象是本地时间。如果前端直接把 new Date() 发给后端，会丢失时区信息。
最佳实践：前端始终发送 ISO 8601 格式的 UTC 字符串 或 带时区偏移的字符串（如 2023-07-04T09:00:00-07:00）。
或者，前端发送 LocalDateTime 字符串 + TimeZoneId，由后端统一转换。
推荐：让后端接收 userTimeZone，前端只负责展示。前端使用 Intl.DateTimeFormat API 进行本地化展示，不要在前端做复杂的时区计算。3. 数据库时区设置MySQL：确保 time_zone 变量设置为 SYSTEM 或 UTC。所有 TIMESTAMP 类型字段自动按 UTC 存储。DATETIME 类型不转换，存储的是输入值，所以强烈建议使用 TIMESTAMP 类型存储 UTC 时间。
PostgreSQL：使用 timestamptz 类型，它自动存储 UTC 时间，并根据 session time zone 进行展示转换。小结
处理【加州时差】这类问题，核心不在于你会几种语言，而在于你是否理解“绝对时间”与“相对时间”的区别。存储：永远存 UTC (Instant / timestamptz)。
转换：使用 IANA 时区 ID (America/Los_Angeles)，利用 ZoneId 自动处理夏令时。
测试：必须覆盖 DST 切换的边界日期，硬编码偏移量是死路。
维护：关注 JDK 升级和 TZDB 更新，时区规则会变，代码要能跟上。这个【完整示例】不仅适用于加州，也适用于东京、伦敦、悉尼。把这套架构搭好，你可以应对全球 99% 的时区问题。剩下的 1% 是那些没有标准时区、使用非标准偏移量的奇葩地区（如印度 UTC+5:30，尼泊尔 UTC+5:45），但 IANA ID 依然能处理。
这个知识点你面试被问过吗？留言说说。 特别是那些关于“为什么不用 Date 类而用 Instant”或者“如何测试夏令时切换”的问题，看看大家的回答有多离谱。 3个代码搞定加州时差计算，附完整示例
3个代码搞定加州时差计算，附完整示例
学会语法却不知怎么搭项目？别急，今天直接上硬菜。很多应届生背熟了 Python 或 Java 的日期类，一到实战处理跨时区业务就懵圈，尤其是像【加州时差】这种涉及夏令时（DST）切换的复杂场景。光看文档不够，必须手敲一遍【完整示例】，才能把 ZoneId、OffsetDateTime 和数据库存储的坑填平。
这篇文章不玩虚的，我们从一个真实的“全球协作日历提醒系统”切入，手把手带你从零搭建一个能正确处理美西时间的后端模块。你会看到目录怎么建、代码怎么拆、测试怎么写，以及如何在生产环境避免“时间漂移”。
项目目标与业务场景
我们要解决的问题很具体：一个 SaaS 平台允许用户设置提醒，但服务器部署在 UTC 时区，用户分布在旧金山、纽约和北京。当用户在旧金山（太平洋时间 PT）设置“明天上午 9 点提醒我开会”，系统必须准确计算出 UTC 时间，并在正确的时刻触发推送。
难点在于：加州遵循太平洋时间标准，一年中会进行两次夏令时切换（3月第二个周日和11月第一个周日）。这意味着，同样的“上午9点”，在1月和7月对应的 UTC 偏移量是不同的（UTC-8 vs UTC-5）。如果只用简单的 hours + 8 硬编码，你的系统会在每年3月和11月出错，导致提醒早到或迟到3小时。
我们的目标是：准确解析：正确处理带时区信息的用户输入。
统一存储：数据库只存 UTC 时间，避免时区污染。
动态转换：根据用户所在时区，在展示层实时转换，支持夏令时自动调整。这不是玩具代码，而是生产级架构的缩影。下面我们从工程结构开始。
目录结构与工程初始化
不要把所有代码塞在一个文件里。对于涉及时间处理的模块，清晰的分层至关重要。假设我们使用 Java 17 + Spring Boot 3，因为 Java 的 java.time 包是处理时区的最佳实践之一（Python 的 zoneinfo 也类似，逻辑通用）。
项目结构如下：
src/main/java/com/example/timezone/
├── controller
│ └── ReminderController.java # 接收用户请求
├── service
│ ├── TimeZoneService.java # 核心时区转换逻辑
│ └── ReminderService.java # 业务逻辑（创建、查询提醒）
├── model
│ ├── Reminder.java # 数据模型
│ └── UserPreference.java # 用户时区偏好
├── util
│ └── TimeUtils.java # 辅助工具类
└── exception└── TimeZoneParseException.java # 自定义异常关键点：TimeZoneService 是独立的服务层，不依赖具体的数据库实现。这样我们可以轻松替换时区库（比如从 java.time 切换到 Joda-Time，虽然前者已内置，但架构上要保持解耦）。
初始化 Maven 依赖，确保使用 JDK 8+ 的 java.time，无需额外引入第三方库（除了测试用的 JUnit 5）。这是最干净的做法，因为 JDK 内置的时区数据库（TZDB）会随 JDK 更新，而手动维护时区数据是灾难的开始。
核心代码实现与逐行讲解
1. 数据模型设计
Reminder 实体只存储 UTC 时间戳，这是铁律。
import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import jakarta.persistence.Column;
import java.time.Instant;@Entity
public class Reminder {@Idprivate Long id;// 存储绝对时间点，与时区无关@Column(nullable = false)private Instant triggerTimeUtc;// 存储用户创建提醒时所在的时区 ID，如 America/Los_Angeles@Column(nullable = false)private String userTimeZoneId;// ... 其他字段
}为什么存 Instant 而不是 LocalDateTime？
LocalDateTime 没有时区信息，它只是一个“日历时间”。如果存 LocalDateTime，当用户从旧金山飞到纽约，你无法判断他指的是“旧金山的9点”还是“纽约的9点”。Instant 是绝对时间，对应地球上的某一瞬间，是唯一安全的存储格式。
2. 核心转换逻辑
这是文章的灵魂。TimeZoneService 负责处理所有的时区数学题。
import org.springframework.stereotype.Service;
import java.time.*;
import java.time.zone.ZoneRules;@Service
public class TimeZoneService {/*** 将用户输入的“当地日期时间”转换为 UTC Instant* @param localDateTime 用户看到的日期时间，如 2023-07-04T09:00* @param zoneId 用户所在时区，如 America/Los_Angeles* @return UTC 时间戳*/public Instant convertToUtc(LocalDateTime localDateTime, String zoneId) {// 1. 获取时区规则，这里会自动处理夏令时ZoneId zone = ZoneId.of(zoneId);// 2. 将 LocalDateTime 绑定到 ZoneId，得到 ZonedDateTime// 注意：ZonedDateTime 知道此时是 PDT (UTC-7) 还是 PST (UTC-8)ZonedDateTime zonedDateTime = localDateTime.atZone(zone);// 3. 转换为 Instant (UTC)return zonedDateTime.toInstant();}/*** 将 UTC Instant 转换回用户当地的 LocalDateTime (用于展示)* @param utcInstant 数据库中的 UTC 时间* @param zoneId 当前用户查看时所在的时区* @return 用户当地的日期时间*/public LocalDateTime convertToUserLocal(Instant utcInstant, String zoneId) {ZoneId zone = ZoneId.of(zoneId);return utcInstant.atZone(zone).toLocalDateTime();}
}逐行拆解：ZoneId.of(America/Los_Angeles)：这是 IANA 时区数据库的标准 ID。严禁使用 PST 或 PDT 这种缩写，因为它们不区分年份，无法正确处理历史夏令时规则。IANA ID 是唯一的、标准的、可追溯的。
localDateTime.atZone(zone)：这一步是核心。它不是简单加偏移量，而是查询 ZoneRules。在 2023 年 7 月，它会查到偏移量是 -7:00；在 2023 年 1 月，查到的是 -8:00。
RFC 规范背景：虽然 HTTP 头中的时区标识符有 RFC 822 等历史规范，但现代应用普遍遵循 IANA Time Zone Database 标准。Java 的 ZoneId 直接映射 IANA ID，保证了与操作系统、浏览器时区数据库的一致性。如果你发现前端 JS 的 Date 对象和后端 Java 的时间不一致，99% 是因为时区 ID 不匹配或 TZDB 版本落后。3. 控制器层：接收与校验
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;@RestController
@RequestMapping(/api/reminders)
public class ReminderController {private final TimeZoneService timeZoneService;private final ReminderService reminderService;// 构造函数注入public ReminderController(TimeZoneService timeZoneService, ReminderService reminderService) {this.timeZoneService = timeZoneService;this.reminderService = reminderService;}@PostMappingpublic ResponseEntityString createReminder(@RequestBody ReminderRequest request) {// 1. 解析用户传入的字符串时间，格式必须严格LocalDateTime userLocalTime = LocalDateTime.parse(request.getTime(), DateTimeFormatter.ISO_LOCAL_DATE_TIME);// 2. 获取用户声明的时区，并进行合法性校验String userZone = request.getUserTimeZone();if (!TimeZoneService.isValidZone(userZone)) {throw new IllegalArgumentException(Invalid time zone ID: + userZone);}// 3. 转换并存储reminderService.create(userLocalTime, userZone);return ResponseEntity.ok(Reminder created);}// 辅助静态方法public static boolean isValidZone(String zoneId) {try {ZoneId.of(zoneId);return true;} catch (Exception e) {return false;}}
}避坑指南：不要信任客户端时间：客户端传来的 time 字段只是“用户认为的当地时间”，我们必须结合 userTimeZone 才能还原真实时刻。
校验时区 ID：用户可能手误输入 Los_Angeles 而不是 America/Los_Angeles。ZoneId.of 会抛异常，我们要捕获并返回友好的错误信息。运行与测试：验证夏令时边界
写代码不测试，等于没写。特别是时区代码，必须覆盖夏令时切换的边界日期。
1. 单元测试用例
我们使用 JUnit 5 编写测试。重点关注 2023 年的两个切换点：开始夏令时：2023-03-12 02:00 (PST) - 03:00 (PDT)
结束夏令时：2023-11-05 02:00 (PDT) - 01:00 (PST)import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;
import java.time.*;class TimeZoneServiceTest {private final TimeZoneService service = new TimeZoneService();@Testvoid testSummerTimeConversion() {// 7月4日，加州是 PDT (UTC-7)LocalDateTime local = LocalDateTime.of(2023, 7, 4, 9, 0);String zone = America/Los_Angeles;Instant utc = service.convertToUtc(local, zone);// 期望 UTC 是 16:00 (9 + 7 = 16)ZonedDateTime expectedUtc = ZonedDateTime.ofInstant(Instant.parse(2023-07-04T16:00:00Z), ZoneOffset.UTC);assertEquals(expectedUtc.toInstant(), utc);}@Testvoid testWinterTimeConversion() {// 1月1日，加州是 PST (UTC-8)LocalDateTime local = LocalDateTime.of(2023, 1, 1, 9, 0);String zone = America/Los_Angeles;Instant utc = service.convertToUtc(local, zone);// 期望 UTC 是 17:00 (9 + 8 = 17)ZonedDateTime expectedUtc = ZonedDateTime.ofInstant(Instant.parse(2023-01-01T17:00:00Z), ZoneOffset.UTC);assertEquals(expectedUtc.toInstant(), utc);}@Testvoid testDstTransitionBoundary() {// 2023-03-12 是切换日// 02:30 PST 是不存在的（时钟从 02:00 跳到 03:00）// 这里测试一个有效的跨越点：02:59 PSTLocalDateTime local = LocalDateTime.of(2023, 3, 12, 2, 59);String zone = America/Los_Angeles;Instant utc = service.convertToUtc(local, zone);// 02:59 PST (UTC-8) = 10:59 UTCassertEquals(Instant.parse(2023-03-12T10:59:00Z), utc);// 测试 03:01 PDT (UTC-7)LocalDateTime localAfter = LocalDateTime.of(2023, 3, 12, 3, 1);Instant utcAfter = service.convertToUtc(localAfter, zone);// 03:01 PDT (UTC-7) = 10:01 UTCassertEquals(Instant.parse(2023-03-12T10:01:00Z), utcAfter);}
}观察：注意 testDstTransitionBoundary 中的时间跳变。02:59 PST 是 10:59 UTC，而 03:01 PDT 是 10:01 UTC。时间在“前进”了，但 UTC 时间倒退了？不，是时区偏移量变了。从 UTC-8 变成 UTC-7，相当于“快”了1小时。这段代码如果写成硬编码偏移量，绝对通不过测试。
2. 集成测试
模拟一个完整的 HTTP 请求，确保 Controller 和 Service 协作正常。
@Test
void testCreateReminderWithInvalidZone() {// 使用 MockMvc 发送请求// 预期返回 400 Bad Request// 验证错误消息包含 Invalid time zone ID
}优化扩展与生产环境避坑
1. 时区数据库更新问题
JDK 的时区数据库（TZDB）是静态的。如果某个国家（如智利）突然改变夏令时规则，而你的 JDK 版本较旧，你的代码会算错。
解决方案：定期升级 JDK：这是最根本的办法。
使用可更新的 TZDB：Java 9+ 允许通过 java.time.tzdb 包指定外部 TZDB 文件。在 Spring Boot 中，你可以配置 spring.jdk.timezone.database 指向一个最新版本的 TZDB 文件，实现热更新。
监控时区变更：订阅 IANA 的时区变更通知（tz-announce 邮件列表）。2. 前端与后端的时区协同
前端 JavaScript 的 Date 对象是本地时间。如果前端直接把 new Date() 发给后端，会丢失时区信息。
最佳实践：前端始终发送 ISO 8601 格式的 UTC 字符串 或 带时区偏移的字符串（如 2023-07-04T09:00:00-07:00）。
或者，前端发送 LocalDateTime 字符串 + TimeZoneId，由后端统一转换。
推荐：让后端接收 userTimeZone，前端只负责展示。前端使用 Intl.DateTimeFormat API 进行本地化展示，不要在前端做复杂的时区计算。3. 数据库时区设置MySQL：确保 time_zone 变量设置为 SYSTEM 或 UTC。所有 TIMESTAMP 类型字段自动按 UTC 存储。DATETIME 类型不转换，存储的是输入值，所以强烈建议使用 TIMESTAMP 类型存储 UTC 时间。
PostgreSQL：使用 timestamptz 类型，它自动存储 UTC 时间，并根据 session time zone 进行展示转换。小结
处理【加州时差】这类问题，核心不在于你会几种语言，而在于你是否理解“绝对时间”与“相对时间”的区别。存储：永远存 UTC (Instant / timestamptz)。
转换：使用 IANA 时区 ID (America/Los_Angeles)，利用 ZoneId 自动处理夏令时。
测试：必须覆盖 DST 切换的边界日期，硬编码偏移量是死路。
维护：关注 JDK 升级和 TZDB 更新，时区规则会变，代码要能跟上。这个【完整示例】不仅适用于加州，也适用于东京、伦敦、悉尼。把这套架构搭好，你可以应对全球 99% 的时区问题。剩下的 1% 是那些没有标准时区、使用非标准偏移量的奇葩地区（如印度 UTC+5:30，尼泊尔 UTC+5:45），但 IANA ID 依然能处理。
这个知识点你面试被问过吗？留言说说。 特别是那些关于“为什么不用 Date 类而用 Instant”或者“如何测试夏令时切换”的问题，看看大家的回答有多离谱。