結算時間存 UTC，香港日報為甚麼落錯日？

先準備用來排查的資料

本例匯出存的是 UTC，營運日則明確用快八小時的時間。先取 UTC 日期會弄錯午夜界線。要先換算完整時間再取日期，原 UTC 值仍保留供對帳。

以下完整建表及資料只在新的 SQLite 測試資料庫執行。全部紀錄均為假設，數量以件計，輸入的 cents 金額欄以貨幣的分存整數；計算後的平均數可能不足整分。小型例子的各表均完整列在預覽。

CREATE TABLE settlements(id TEXT PRIMARY KEY,utc_at TEXT,amount_cents INTEGER);
INSERT INTO settlements VALUES ('S1','2026-10-09 15:30:00',10000),('S2','2026-10-09 16:30:00',20000);

重現錯誤結果，再核對更正

SELECT date(utc_at) AS business_day,SUM(amount_cents) AS settled_cents FROM settlements GROUP BY business_day ORDER BY business_day;

SELECT date(utc_at,'+8 hours') AS business_day,SUM(amount_cents) AS settled_cents
FROM settlements GROUP BY business_day ORDER BY business_day;

15:30 UTC 按本例是 10 月 9 日 23:30；16:30 UTC 則是 10 月 10 日 00:30。錯誤報表把 30000 分全放在 9 日，更正後分別是 10000 及 20000 分。

套用前先測邊界及資料範圍

加入剛好 16:00 UTC，換算為下一日 00:00，10 月 10 日合計變 25000 分。

邊界測試要另開新的假設資料庫，重做完整建表及資料，只套用以下改動，再執行更正查詢。測試改動不可用於正式系統。

INSERT INTO settlements VALUES ('S3','2026-10-09 16:00:00',5000);

UTC+8 是明示測試條件，不能自動辨別時區。不同偏移、夏令時間及供應商截數規則須另處理。

以上錯誤、更正及邊界結果都已在 SQLite 執行，並與另行編寫的預期資料逐行核對。證據只適用於這組假設條件，未測其他資料庫、正式效能或你的現有資料結構。