跨時區開發中，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的知識面再廣，它也想不到“騙時間”這種歪招——因為它不敢提這種方案，它太“正直”了，不像人類程序員這樣“又懶又壞還有效”。

最后的實現

我的方案非常簡單，只做兩件事：

1. 用 Intl.DateTimeFormat 獲取新西蘭當前偏移量（動態判斷是否夏令時）
2. 在用戶選完日期后，手動加上這個小時數，直接塞進 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;}
};

有時候，最聰明的不是AI

你可以讓AI寫代碼、查bug、做重構。但它無法替代你站在“真實用戶”和“現有代碼”的縫隙中，找到那個最合適的、最省事的方案。

這種Bug，就是典型的：

• 你說它不是Bug吧，它確實出錯了；
• 你說它是Bug吧，代碼哪哪都沒寫錯。

最終解決它的不是完美設計，而是一點點工程直覺和一點點狡猾。

---

這就是“AI無法解決的Bug系列”的第一篇。
如果你也踩過這種坑，別急著問AI，先問問自己：
我能不能騙一騙它？

下集見。