週一早上九點，日報準時到了。標題寫著“昨日業績”，數字卻來自還沒結束的洛杉磯週日。營運主管以為在比較兩個完整日，實際比較的是一天和半天。
準點啟動與資料完整，是兩件事。 AI automation timezone 的配置只回答任務何時執行；它不會替你決定上游的一天何時結束、報告該歸哪一天。
在 Buda 中，Skills 定義方法，Automations 定義執行時機。把日期判斷寫進方法，再討論排期，才能避免任務守時、結論失真。
先給三個時鐘各自命名
- 排程時鐘： 任務在哪個 IANA 時區、幾點啟動，例如
Asia/Shanghai的週一09:00。 - 來源日曆： 資料提供方按哪個時區劃分日期，例如
America/Los_Angeles的00:00至次日00:00。 - 報告業務日： 團隊把這份報告歸到哪天，以及報告實際要比較的哪段資料。
報告日期不是讀取日期，也不是來源日期的別名。同一份上海週一的經營簡報，可以合法使用洛杉磯週六的完整資料，但必須直接寫清截止日。不能改一個標題就把它變成周日業績。
同一個九點，來源日還沒結束
以下是虛構的內部日報場景，使用真實 IANA 時區換算；不是某次 Buda 執行記錄，也不聲稱上游具有固定釋出延遲。
2026年10月19日，週一，上海09:00，對應洛杉磯10月18日週日18:00。洛杉磯的週日還剩六小時。它要到上海週一15:00才結束。
| 上海時間 | 洛杉磯時間 | 能對週日資料作什麼判斷 |
|---|---|---|
| 10月19日09:00 | 10月18日18:00，PDT | 日曆尚未閉合，不能標完整 |
| 10月19日15:00 | 10月19日00:00，PDT | 週日結束，但不代表來源已完成入庫 |
| 來源明確確認完成之後 | 以來源實際狀態為準 | 才能接受該來源日完整性 |
來源週日的範圍應寫為半開區間 [2026-10-18 00:00, 2026-10-19 00:00)，時區是 America/Los_Angeles；換成上海時間是 [10月18日15:00, 10月19日15:00)。這樣沒有“23:59:59是否含最後一秒”的歧義。
上海的“日曆昨日”則是10月18日00:00至19日00:00。週一09:00往前滾動24小時是10月18日09:00至19日09:00。這三段區間都不一樣。 標成“昨天”會掩蓋差異，表格應該帶區間與時區。
給每次執行一張日曆契約
不要只寫“每天九點分析昨天”。在任務輸入或Skill方法中，記錄以下欄位。它們是一份建議的資料契約，不是Buda自動生成的系統鎖或完整性保證。
報告業務日：2026-10-19（Asia/Shanghai）
計劃啟動：09:00（Asia/Shanghai）
來源：已授權的洛杉磯營運資料
來源日：2026-10-18（America/Los_Angeles）
來源範圍：[10-18 00:00, 10-19 00:00)
期望比較：前一個同口徑完整來源日
data-through：來源實際返回的最新資料日期，不按讀取時刻填寫
完整度：來源確認；未知則為null，不是0或complete
最早可用：不早於上海15:00；入庫延遲另向來源確認
業務鍵：來源ID + 來源日期 + 報告型別 + 版本
待確認：釋出延遲、修訂規則、誰決定等待或partial
業務鍵用於找到已有產物，不等於原生冪等鎖。若同一業務日需要修訂，就保留舊版本並記錄版本關係。來源最後更新日期、覆蓋截止時間與報告生成時間分別儲存，不混成一個 updatedAt。
如果來源按事件時間記賬，還需確認日期過濾的是事件時間還是匯入時間。時區換算解決不了遲到事件和後補資料：來源日已經結束，資料仍可能被修訂。
源日沒閉合，不要硬湊一個完整日報
在虛構的週一09:00例子裡，可選擇兩種明確交付，具體由負責人決定：
- 等待該來源日。 輸出“洛杉磯10月18日尚未結束，最早日曆閉合為上海15:00；入庫完成時間待來源確認”。這是狀態說明，不是假裝拿到了週日完整結果。
- 交付partial。 如果確實已有截至洛杉磯週六的完整資料，就寫“報告業務日10月19日；本次資料截至洛杉磯10月17日；週日未完成”。不可比區間不計算日環比。沒有經過核驗的完整日，就不補一個數。
決定等待不等於系統會自動暫停、自動重試或改排期。想增加後續執行，需要單獨確定授權與執行方式。當前方法只負責輸出清楚的狀態。
夏令時改變的是偏移，不是業務含義
2026年11月2日，上海週一09:00，對應洛杉磯週日17:00，已經是PST。洛杉磯週日閉合改為上海週一16:00，而不是十月的15:00。
保留 America/Los_Angeles，每次按具體日期換算；不要把“北京時間減15小時”寫成永久規則。上例十月差15小時，十一月差16小時。上海的09:00排程仍是09:00，變的是兩地對應時刻。
若任務排在實行夏令時地區的本地凌晨，某些日期會出現不存在或重複的本地時刻。先明確排程器對這些情況的處理，並用具體日期檢查；不知道其行為就不要承諾每次恰好執行一次。
用三種輸入檢查方法，而不是立即建任務
| 建議檢查 | 輸入狀態 | 期望輸出 |
|---|---|---|
| 正常 | 來源日已閉合，來源確認完整 | 明示業務日、來源區間、截止日和可比前窗 |
| 延遲 | 日曆閉合但來源未確認，或仍缺一部分 | 等待/partial及具體缺口；不把未知寫成0 |
| 重複 | 同業務鍵已有產物，或上次傳送狀態未知 | 找到已有版本；核清狀態後再由人決定，不盲重發 |
這些是未執行的驗收請求，不是已透過的測試。保留輸入、實際輸出和負責人結論。重複執行檢查需要實際讀取狀態；如果檔案存在但無法確認是否傳送，檔案本身不能證明傳送成功。
日期口徑常見問題
來源只有日期，沒有時區，能先猜一個嗎？
不能。日期邊界決定哪些事件被納入。先向來源負責人確認時區和完整度定義；報告標明來源時區未知，並暫停跨日比較。不要按瀏覽器或當前操作者的時區替它填空。
來源日結束了，為什麼仍不能說完整？
日曆閉合是必要條件，來源完成是另一條件。核對data-through、實際覆蓋及遲到資料規則。若只能知道日期已結束，完整度仍應保持未知。
報告第二天重新執行，歸檔日期要改嗎？
保持原報告業務日及來源區間，另外記錄重新執行時間與修訂版本。否則一個業務日會被拆成多份看似新報告。重複傳送狀態未知時先查記錄，不因重新生成成功就再發一次。
先讓一份樣例把日期說清楚
把已確認的三個時鐘和停止條件交給 Buda Agent，要求先生成一份日期說明與待確認清單，不建立任務、不發訊息。在Agent tab檢視工具輸入和實際檔案，確認它沒有把讀取時間當資料截止日。
規則反覆使用時，可以在 Buda AI 的 Marketplace 搜尋並安裝合適的Skill，檢查它是否接受這些日期輸入。一句話日報能簡化執行入口，但跨地區的日曆判斷仍需先說清；格式自動化不會替團隊定義“昨天”。