被Polymarket坑了，這次出的bug是「時間扭曲」
- 核心觀點：Polymarket預測市場因採用美東時間（ET）作為計時標準，未妥善處理夏令時切換，導致其「加密貨幣漲跌」預測事件的時間週期顯示與API數據出現邏輯混亂，暴露了其底層設計在走向金融基礎設施時，未能遵循UTC時間等關鍵工程標準的問題。
- 關鍵要素：
- 事件發生在美東時間冬令時向夏令時切換的3月8日凌晨，時鐘從2:00直接跳至3:00，導致1:00開始的1小時預測事件計時出現異常。
- Polymarket前端和API將該批事件的時間週期錯誤地顯示為「March 8, 1-1 AM ET」，而非正常的1小時區間，這造成了邏輯上的不可能狀態。
- 有用戶表示，依賴API結束時間進行判斷的自動化交易程式因此出現故障，預估虧損超過10萬美元。
- 爭議根源在於Polymarket採用了會隨季節切換的美東時間，而非現代金融系統普遍採用的、全球一致的UTC時間作為底層計時標準。
- 該事件雖影響範圍有限，但揭示了預測市場在工程標準上與傳統金融基礎設施的差距，自動化交易的普及放大了此類時間設計缺陷的風險。
原創 | Odaily（@OdailyChina）
作者｜Azuma（@azuma_eth）
在常規認知下，時間是線性的，但加密世界卻存在「例外」。
昨日，美東時間（ET）依照慣例（一般是三月第 2 個星期天的凌晨 2:00）完成了冬令時向夏令時的切換，時鐘向前撥動了一個小時，從 3 月 8 日 2:00 直接跳到了 3:00。時間並沒有憑空溜走，只是美東地區會根據習俗切換冬令時（EST）和夏令時（EDT），其目的在於人為調整時間刻度，進而更充分地利用白天日照時間（順便省電）。
對於人們的日常生活而言，這一切換並不會帶來太大影響，但在預測市場 Polymarket 之上，昨天的時區切換卻直接引發了意外爭議。
Polymarket 撞上計時爭議
爭議發生於 Polymarket 上的「加密貨幣漲跌」預測事件。
Polymarket 提供了以年、月、週、日、4 小時、1 小時、15 分鐘、5 分鐘為時間範圍的加密貨幣漲跌預測事件，支援 BTC、ETH、SOL、XRP 等主流代幣，這些事件會根據美東時間自動創建、結算，如今已是 Polymarket 上重要的交易量來源之一。
3 月 8 日凌晨 1:00（此時仍處於美東時間冬令時）， Polymarket 上線了新一期 BTC、ETH、SOL、XRP 的 1 小時漲跌預測事件。相關事件連結如下。
- BTC（最終判定結果：上漲）：https://polymarket.com/event/bitcoin-up-or-down-march-8-1am-et
- ETH（最終判定結果：下跌）：https://polymarket.com/event/ethereum-up-or-down-march-8-1am-et
- SOL（最終判定結果：下跌）：https://polymarket.com/event/solana-up-or-down-march-8-1am-et
- XRP（最終判定結果：下跌）：https://polymarket.com/event/xrp-up-or-down-march-8-1am-et
依照事件的判定規則 —— 取 Binance USDT 交易對中，事件開始起 1 小時蠟燭圖的開盤價與收盤價對比情況 —— 上述四個事件當前均已結算完成。
但由於本批事件的結束時間恰好撞上了夏令時切換，美東時間在觸達 2:00 的那一瞬間直接跳到了 3:00（即 2:00 - 3:00 這一時間段被跳過了），導致 Polymarket 平台本身對這一批事件的計時出現了一定混亂。
如 Polymarket 前端界面所示，或是因為 2:00 在昨日美東時間的計時中並不存在，本批事件當前所呈現的時間週期均為「March 8，1-1 AM ET」（即 3 月 8 日 1:00 - 1:00），但在正常計時狀態下，此類事件本應呈現一個 1 個小時的時間週期（比如前一天的同類事件為「March 7，1-2 AM ET」，即 1:00 - 2:00），而若計入夏令時切換的影響，本批事件更合理的時間週期應為「March 8，1-3 AM ET」（即 1:00 - 3:00，實質仍為 1 個小時）。
所以無論怎麼去看，前端當前所顯示的「March 8，1-1 AM ET」都很奇怪。
中文區用戶「小Z」（@richrichardoz）就此於 X 發文表示，除去前端之外，Polymarket 的 API 也呈現了「1-1 AM ET」的時間週期，導致根據 API 返回數據做的自動程序「全炸了」，預估因此虧損超過 10 萬美元。
「小Z」就此補充解釋道，開始時間和結束時間完全一樣，這是一個邏輯上不可能存在的市場狀態。很多自動化交易系統都會依賴結束時間（end time）來判斷交易窗口，這個錯誤直接導致其程序虧了一大筆錢。因此，建議 Polymarket 將相關事件的時間標準更改為 UTC 時間，並賠償因為數據問題而受到影響的用戶。
除了該用戶而言，外網亦有不少用戶在相關事件的下方留言表達疑惑，但截至發文，Polymarket 尚未通過官方渠道予以回覆。
傳統金融市場的時間標準
回看這場爭議，影響規模雖然並不算大，但卻暴露了 Polymarket 在「加密貨幣漲跌市場」事件中的一個底層設計缺陷。
受歷史習俗、經濟地位以及行業慣例等因素影響，美東時間在各行各業依然被廣泛使用。但這對金融系統而言其實並不友好，原因在於美東時間每年都會在夏令時與冬令時之間進行切換 —— 即在特定時間將時鐘人為撥快或撥慢一個小時，從而分別造成時間的「跳躍」與「重疊」。
而在現代金融系統中，UTC 時間早已成為事實上的通用標準。在絕大多數金融基礎設施中，內部系統通常都會使用 UTC 時間戳作為唯一標準時間，美東時間等本地時間雖然仍在沿用，但在系統邏輯上往往只存在於面向用戶的展示層。這一設計正是為了避免時間系統的不確定性，確保在金融交易、清算與自動化系統中，時間始終保持單調、唯一且全球一致。
Polymarket 此次爭議的關鍵矛盾正在於，相關事件採用了美東時間作為計時標準，但卻未能充分考慮夏令時切換所帶來的潛在變量，最終導致前端與 API 數據出現混亂。在當下的預測市場用戶群體中，越來越多參與者已經通過 API 和自動化程序進行交易，一些原本只影響前端顯示的小問題，很容易在自動化系統中被放大為真實的資金損失。
從結果來看，這場爭議或許並不算什麼嚴重事故，理論上每年最多也只可能出現兩次，但它所揭示的卻是一個更為嚴肅的設計問題 —— 當預測市場逐漸走向金融基礎設施時，它也必須遵循金融基礎設施所採用的工程標準。
