当前位置：首页 > news >正文

AI无法解决的Bug系列（一）跨时区日期过滤问题

news 来源：原创 2025/5/21 5:15:17

跨时区开发中，React Native如何处理新西兰的日期过滤问题

有些Bug，不是你写错代码，而是现实太魔幻。

比如我最近给新西兰客户开发一个React Native应用，功能非常朴素：用户选一个日期范围，系统返回该范围内的日志。

很简单对吧？结果客户连着几天发消息抱怨：

“我选 4 月 30 日，结果一个日志都没有。”
“我选 29 到 30 日，它却只给我 28 日的内容？”

我这边一看，数据库明明有数据，接口逻辑也没问题。我自己一测，一切正常。

奇怪的分界线：12 点

后来我逐渐发现一个微妙的规律：客户上午测试就报错，我这边是中午12点以后测试的，每次都正常。

这让我突然意识到一个关键问题——新西兰时区比UTC快整整 12 或 13 小时（取决于是否夏令时）。

所以客户早上选“今天”的时候，其实是：

新西兰时间：2025-04-30 09:00
转成UTC：2025-04-29 21:00

后台拿到UTC一查：29 号？当然没有 30 号的日志，客户当然觉得你系统出错。

AI登场：一本正经地告诉我“你没转换时区”

我让AI帮忙分析，它第一句话就是：

“请将前端的日期转换为 Pacific/Auckland 时区再传给后端。”

我笑了。这当然是“正解”，可惜我们用的前端组件（DatePicker那一类）永远返回的是UTC，你再怎么本地转换，它最后还是给你一个 2025-04-29T12:00:00.000Z。

这不就等于我洗了一遍手，又摸回原来的脏东西上。

插曲一：传字符串行不行？

我一度觉得，既然组件不行，那干脆直接传字符串吧，比如 "2025-04-30" 这种明明白白的格式。

于是我建议大家传字符串，再在后端统一用 new Date("2025-04-30") 来解析。

听起来确实不错，结果一试……全系统几十个地方涉及日期格式解析、比较、展示，全都要重写，组件也不认字符串了，还得加一堆格式化处理。

我沉默了 5 秒钟，打回这个提议。

还是太重了，伤筋动骨，放弃。

插曲二：传个“假UTC”看看？

我灵光一闪：如果我硬要前端传 UTC 时间，那我干脆就“骗”它一下好了！

用户选 2025-04-30，我就手动往这个时间里加 12 或 13 小时，让它看起来像 UTC，但其实它表示的是新西兰时间。

比如：

// dateFrom: 2025-04-30T00:00:00 NZT
// -> 调整后发送：2025-04-29T12:00:00Z（UTC格式）

这样一来：

组件依旧开心，传的是 Date
后端逻辑不动，处理的是 UTC
看上去合规，实际上我们偷偷塞了个“假的UTC”进去

我把这个方案告诉AI，它思考了两秒钟，回答说：

“唯一的缺点是，从技术严格性角度来看，这不是一个‘正确’的解决方案。但从实用角度看，它完全解决了问题，并且代码干净简洁。”
“这种方法本质上是通过人为调整时间来补偿时区差异，而不是通过标准的时区转换机制。”

我：？？？
你前面怎么没提这个方案？

只能说，AI的知识面再广，它也想不到“骗时间”这种歪招——因为它不敢提这种方案，它太“正直”了，不像人类程序员这样“又懒又坏还有效”。

最后的实现

我的方案非常简单，只做两件事：

用 Intl.DateTimeFormat 获取新西兰当前偏移量（动态判断是否夏令时）
在用户选完日期后，手动加上这个小时数，直接塞进 Date 对象里传给后端

后端收到的是标准UTC，但时间已经被我偷偷换过了。

业务逻辑不动，UI正常，所有日志都对上了。

const getNZOffsetHours = () => {try {const now = new Date();const formatter = new Intl.DateTimeFormat('en-US', {timeZone: 'Pacific/Auckland',timeZoneName: 'short'});const formatted = formatter.format(now); // e.g., "4/30/2025, NZST"const match = formatted.match(/GMT([+-]\d+)/);return match && match[1] ? parseInt(match[1], 10) : 12;} catch {return 12;}
};