業務時間：訂單與對帳使用一致的期間邊界

訂單、退款與每日對帳可能在不同時間執行。如果期間邊界取決於伺服器或瀏覽器的時區，同一個事件就可能被分到不同報表。

平台以明確的業務時區計算期間與營運日期。重點是讓這項政策共用、可測試。以下使用 UTC 作為示意設定，不公開客戶的實際配置。

分開處理時間點與業務日期

事件時間回答事情何時發生；業務日期決定它屬於哪個報表期間；格式化字串決定讀者看到什麼。

PostgreSQL 的 timestamptz 代表一個時間點。改變連線時區，影響顯示方式，不會改變事件發生的時間；原始輸入時區也不會自動保留成另一項業務資料。

使用左閉右開的期間查詢

每日對帳與其他期間判斷，先計算邊界，再傳入查詢：

SELECT *
FROM business_events
WHERE occurred_at >= $1
  AND occurred_at < $2;

期間包含起點、不包含終點，不必猜測一天的最後一毫秒，也不會讓相鄰期間在交界處重複計算。

明確指定時區的分組範例：

SELECT (occurred_at AT TIME ZONE 'UTC')::date AS business_date,
       count(*)
FROM business_events
GROUP BY 1;

直接將 timestamptz 轉為 date，則會依賴連線時區。當同一份報表在不同環境執行時，這就是隱藏的輸入。

對帳要涵蓋跨期間事件

購買與退款可能發生在不同日期。對帳需要納入後來的異動，再找到它所參照的原始交易。只篩選訂單建立日期，就會漏掉退款對今天餘額的影響。

目前日結檢查先依業務期間找出相關異動，再與原始紀錄交叉比對。營運識別也使用同一套日期政策，讓客服與對帳有一致的參考。

驗證邊界

值得測試的情境包括期間切換前後、不同日期發生的退款，以及在不同執行環境時區下運作。預期的業務期間應保持一致。

時區設定是模型的輸入。把它留給執行查詢的機器決定，就會讓帳務期間受到部署環境影響。