夏令时致JWT签发与过期日期校验失败，求全年永久解决方案

这个夏令时的坑我之前做身份认证系统时也踩过！本质问题出在你处理JWT时间字段时，没彻底区分UTC绝对时间和本地时区时间，导致夏令时切换时出现1小时的时间偏移。下面给你几个全年通用的解决方案，按优先级排序：

1. 强制全程使用UTC时间处理JWT时间 #

JWT标准里的签发时间（iss）和过期时间（exp）本质上都是UTC时间戳，但很多时候开发者会不小心用本地时区生成/解析这些时间，这就给夏令时留了漏洞：

• 生成JWT时：直接用UTC时间生成iss和exp，比如Java里用Instant.now()（本身就是UTC），而不是LocalDateTime这类带时区的对象；JS里用Date.now()（本质也是UTC时间戳）或者new Date(Date.UTC(...))。
• 校验时：把getIss()和getExp()的返回值都转换成UTC的Instant（Java）或者时间戳（JS），再进行计算，绝对不要转换成本地时区的日期对象再操作。

2. 直接用时间戳做数值计算，跳过时区转换 #

不要把时间戳转成带时区的日期对象再做减法，直接对getIss()和getExp()返回的毫秒级时间戳做数值运算：

// Java示例：直接用UTC时间戳计算差值
long expMs = jwt.getExp().toInstant().toEpochMilli();
long issMs = jwt.getIss().toInstant().toEpochMilli();
long expectedDiff = 7 * 24 * 60 * 60 * 1000; // 7天的毫秒数
boolean isValid = Math.abs(expMs - issMs - expectedDiff) <= 10;

时间戳本身就是UTC的绝对时间，不受任何时区或夏令时调整的影响，这样计算出来的差值绝对准确。

3. 调整校验逻辑：基于签发时间推导预期过期时间 #

如果担心生成时的时间误差，不如换个校验逻辑：从签发时间getIss()出发，加上7天的UTC时间，再和实际的getExp()对比，允许±10ms的误差：

// Java示例：基于签发时间推导预期过期时间
Instant expectedExp = jwt.getIss().toInstant().plus(Duration.ofDays(7));
Instant actualExp = jwt.getExp().toInstant();
// 校验实际过期时间是否在预期时间的±10ms范围内
boolean isValid = actualExp.isBefore(expectedExp.plusMillis(10)) 
                  && actualExp.isAfter(expectedExp.minusMillis(10));

这种逻辑更直观，也彻底规避了夏令时带来的时区偏移问题——所有时间操作都基于UTC的绝对时间轴，不会出现“丢失/增加1小时”的情况。

总结 #

核心原则就是：所有和JWT时间相关的操作，全程绑定UTC时间，别碰本地时区。UTC时间是连续的绝对时间，不受夏令时、时区调整的影响，这样你的校验逻辑就能全年稳定运行，再也不会出现夏令时相关的异常了。

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