先問報表要回答哪個問題
產品在晚上七時五十九分完成，網路恢復後八時零三分才收到資料，應算哪一班？先看報表目的。若計算產品何時完成，通常使用可信的事件時間；若統計採集服務何時處理資料，則使用指定的收件或處理時間。兩種時間都需要保留。
事件時間是業務事件發生的時間，收件時間是某個接收節點看見資料的時間。系統若經PLC、閘道、訊息服務與資料庫，每一站都有自己的收件時刻。先在欄位定義寫明是哪一層，避免把閘道接收與資料庫提交混為一談。
本文用白班八時至二十時的教學區間，不代表所有工廠班表。班別端點採起點包含、終點不包含，時間已轉成可比較的同一基準。跨時區與夏令時間需另按實際班表處理，不能只比較顯示的時分。
適用於有來源時間及可追溯接收紀錄的事件報表。若設備未提供可信事件時間，必須說明替代時間與限制，不把接收時刻改名叫事件時間就假裝擁有原始製程時間。
用跨班案例比較兩個答案
案例A在十九時五十九分完成、二十時零三分收到。按完成事件時間歸白班；按收件時間歸夜班。兩個結果的差異不代表哪個算術錯誤，而是回答不同問題。正式報表標題與欄位要說明時間依據，避免部門各自使用一種卻直接對帳。
再看案例B於二十時整完成且立即收到。依本例半開區間，它屬下一班。若前班用小於等於二十時、後班又從二十時開始，同一事件會重複；用連續的半開區間可以清楚指定交界歸屬。
假設白班原有九十九件即時資料，案例A晚到一件，按事件時間的最終白班總數是一百件。二十時一分發布的初版只有九十九件並不一定是計算錯，當時資料尚未到齊；應標資料截至時間與是否暫結。
收到晚到事件後，白班摘要可產生修訂版本，夜班的收件統計則記一筆新接收。不要為了讓兩張表數字一致，就把產品產量挪到接收班別；應保留兩種指標之間可追溯的對照。
完成這一步，讀者應能在同一筆事件上找到生產歸屬與接收歸屬，並了解兩者差距來自哪個時間欄位。報表不能只剩日期欄而丟掉原本精度與時區。
先檢查來源時鐘是否可信
若來源時間欄位為空，別默認填成系統最早日期或目前時間而不留標記。明確記錄缺少來源時間及採用的替代依據，讓後續查詢可以區分真實時間與推定歸屬。
來源時鐘若慢五分鐘，直接按事件時間歸班也會錯。保留時鐘同步狀態、時區及已知偏差資訊，設計品質標記與待核對規則。不能看到來源時間早就一律認為是網路補送，它也可能是設備時間錯誤。
延遲可先算指定收件時間減來源時間，但只有時鐘可比時才接近傳輸與排隊耗時。若來源比接收端快十秒，差值可能為負，不能解釋成資料倒流；先查時鐘與時間轉換，再查傳輸。
不要直接修寫原始時間來讓延遲變正。需要校正時，另存校正後時間、方法、偏移及版本，保留原值。時鐘在一天內漂移或跳整時，用單一固定偏移可能不足，需要更細的證據與規則。
若只有收件時間，可發布以收件為準的統計，明確標示不能精確代表事件發生班別。對斷線補送資料可以另列待歸屬，而不是把整包資料全算進收到的那一秒，讓瞬間產量看起來異常暴增。
定義結算窗口與遲到處置
不同用途可有不同等待策略，但同一份報表版本應使用一致規則。生產速報可先提供暫結數，日結報表再補齊；兩者同時標示資料範圍與版本，使用者才不會把合理修訂當成系統任意改數。
先決定報表何時初版、等待多久、何時轉正式，以及正式後仍到達的資料怎麼處理。等待越久可能收得較完整，但使用者更晚拿到結果；這是需求取捨，不能單靠程式預設值替工廠決定。
Azure Stream Analytics文件區分事件時間與抵達輸入來源的時間，並提供晚到及亂序策略。這只是一種產品的處理方式；若流程會調整或丟棄資料，需要在自己的報表契約裡說明，而不是以為指定事件時間後就永遠不漏。
對長時間斷線的歷史補送，可以走另設的重算流程，避免受即時處理窗口限制。原始事件保留、即時視圖與歷史修訂分工清楚，才能同時滿足快速監看與事後完整對帳。
顯示資料截至時間時，也要說明它代表已接收最大事件時間、最後收件時間或已確認完整的時間界線。最大事件時間不等於之前全部資料都到齊，因為中間可能還有缺口。
完成後測試正常到達、跨班晚到、相同事件重送與來源時鐘偏移四種情境，核對產量、接收量及修訂狀態。去重仍是必要前提，選對時間也不能消除重送造成的多算。
練習與常見問題
練習：白班最後一分鐘發生三件事件，其中兩件當班收到，一件晚五分鐘才到。事件時間可信且三件ID不同，最終白班應包含三件；當班收件表只包含兩件，下一班收件表包含另一件。請分別寫報表名稱與時間依據。
失敗時先查報表實際用哪個欄位，再查時區、交界比較、時鐘品質與補送策略。不要先改班表去配合錯誤資料，否則其他正常事件也會一起移位。
問：事件時間一定比收件時間好嗎？答：取決於問題與時鐘可靠性，兩者用途不同。
問：兩個時間差就是網路延遲嗎？答：還可能含來源緩衝、排隊與時鐘偏差。
問：結算後的晚到資料可以直接忽略嗎？答：按明確政策保存與修訂，不能默默消失。
問：最大時間戳到二十時就表示白班完整嗎？答：不一定，亂序與缺漏仍可能存在。
參考：Microsoft Learn Event ordering policies：定義事件與抵達時間並說明晚到、亂序的處理限制。