通过Monkey Patch修改JS Date强制使用UTC的风险与库评估咨询

我们的应用全程使用UTC时间，希望原样展示时间，例如服务器返回的2023-10-10T00:00:00Z始终显示为午夜，无需转换为布拉格当地时间10月10日02:00或纽约当地时间10月9日20:00，仅展示无时区的午夜时间，不涉及夏令时、闰秒等本地时间规则，所有时间均以UTC为准。

我们使用依赖原生Date的Gantt组件，且正从Ant Design v4（基于moment）迁移至v5（拟采用dayjs或date-fns）。现有代码混乱，部分文件为原生Date加减.getTimezoneOffset()，部分文件使用moment.utc()。

我尝试通过Monkey Patch一次性解决该问题，代码如下：

/* eslint-disable no-extend-native, @typescript-eslint/no-unsafe-assignment */
Date.prototype.getTimezoneOffset = () => 0
Object.getOwnPropertyNames(Date.prototype).filter((method) => method.match(/UTC/)).forEach(method => {
  // @ts-expect-error
  Date.prototype[method.replace('UTC', '')] = Date.prototype[method]
}) 
/* eslint-enable */

现正式咨询：

1. 该方案可能引发哪些潜在Bug？
2. 哪些npm库需纳入禁用清单？或如何评估第三方库是否适用？

1. Monkey Patch方案的潜在Bug #

• 方法逻辑冲突风险：虽然当前原生Date的UTC方法和对应本地方法参数一致，但不排除未来JS引擎更新或特殊运行环境中，两类方法出现参数、返回值逻辑差异，直接替换会导致时间处理逻辑错误。
• 遗留代码逻辑失效：原有代码中手动加减getTimezoneOffset()的逻辑，是为了抵消本地时区偏移，现在getTimezoneOffset()固定返回0，这类代码会多执行一次无意义的加减，导致时间计算完全错误。
• 第三方组件逻辑崩溃：你用到的Gantt、Ant Design等组件，内部大概率依赖原生Date的本地方法做时间渲染、计算，强制替换后会彻底打乱它们的时间轴、日历选择等核心逻辑，出现显示异常。
• 日期构造与方法的矛盾：原生new Date('2023-10-10')会按本地时区解析，而替换后的getDate()等方法返回UTC日期，导致构造的时间和后续获取的值出现矛盾，引发难以排查的逻辑bug。
• 调试维护成本剧增：后续开发者排查时间问题时，会默认原生Date的正常行为，很难想到全局Monkey Patch的存在；且JS引擎新增Date方法时，补丁不会自动覆盖，会出现新旧方法行为不一致的情况。

2. 第三方库的评估与禁用清单 #

需优先禁用/谨慎使用的库 #

• 未配置UTC模式的日期库：比如默认本地时区的moment实例（即便你用了moment.utc()，遗漏的代码仍会出错）、未开启UTC插件的dayjs、未指定UTC处理的date-fns。
• 依赖原生Date本地方法的UI组件：未全局配置为UTC模式的Ant Design日期组件、不支持强制UTC的Gantt组件，这类组件会因你的补丁出现显示异常。

评估第三方库是否适用的标准 #

• 是否支持全局强制UTC：查看库文档，确认是否能通过配置（比如dayjs的utc插件、date-fns的UTC工具函数）让所有时间处理基于UTC，无需依赖原生Date本地方法。
• 核心逻辑是否依赖本地方法：查看库源码或社区issue，确认内部是否直接调用getHours()、getDate()等本地方法且无UTC替代方案，这类库要么改配置要么放弃使用。
• 是否有成熟的UTC使用案例：查看官方示例，确认存在全程使用UTC的场景及对应实现方式，确保UTC模式下不会出现时区转换问题。
• 是否修改Date原型：如果库本身也会修改Date原型，会和你的补丁产生冲突，引发不可预期的行为，需谨慎使用。

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