Jest日期时间单元测试本地通过但Jenkins CICD失败如何解决？

问题说明 #

这是日期处理场景非常普遍的时区兼容性问题，核心原因如下：

• 原生Date对象解析带时区标识的时间字符串时，内部会统一转为Unix时间戳存储
• date-fns默认的format方法会基于运行环境的本地时区提取时间字段：你本地是GMT+8时区，所以格式化后得到22:00；Jenkins运行环境是GMT+0时区，格式化后就会得到对应零时区的14:00，最终测试断言失败。

可用修复方案 #

你可以根据业务场景任选以下方案：

方案1：固定单元测试运行时区（无侵入修改，仅需调整测试启动命令） #

在单元测试的启动命令前添加TZ环境变量指定时区为东八区即可，不需要修改任何业务代码和测试用例：

# Linux/Mac环境（Jenkins默认是Linux环境，直接用这个就行）
TZ=Asia/Shanghai npm run test

# Windows环境如果需要本地跑对应配置可以用
set TZ=Asia/Shanghai && npm run test

方案2：调整业务实现，强制按指定时区格式化（永久修复，业务代码也规避时区问题） #

如果业务本身要求输出固定时区的时间，可以用date-fns官方的时区扩展包date-fns-tz实现不受运行环境影响的格式化逻辑：

1. 先安装依赖：

npm install date-fns-tz

2. 修改业务代码：

import { formatInTimeZone } from 'date-fns-tz';

// 默认指定东八区时区，也可以根据业务需要动态传时区参数
function stringToTime(date: string, timeZone = 'Asia/Shanghai') {
    return formatInTimeZone(date, timeZone, 'k:mm');
}

修改后不管运行环境是什么时区，都会按指定时区输出时间，测试和线上业务都不会再出现时区兼容问题。

方案3：调整测试预期值（仅适用于业务要求输出UTC时间的场景） #

如果你的业务逻辑本身就是要输出UTC时区的时间，把测试用例的预期值改为14:00即可，不过该方案适用场景非常有限。

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