Dify 社群提出排程時區修補，新工作流可能顯示本地時間卻以 UTC 執行

Dify 的排程觸發器出現介面顯示與實際執行時間不一致的社群回報。10 月 5 日提交的案例使用 Docker 自架版 1.17.1：新增 Schedule Trigger、不修改設定就發布工作流，面板雖顯示帳號所在時區，儲存的節點資料卻沒有 timezone，後端因此採用 UTC。問題與觸發器設定的持久化有關，尚待上游確認完整影響範圍。問題回報

回報者以紐約帳號示範：畫面顯示每天午夜執行，預期下一次時間為 10 月 6 日 04:00 UTC，但資料庫的排程計畫記錄為當日 00:00 UTC，提前四小時。其根因分析指出，前端會以帳號時區補足顯示值，卻只有在使用者編輯設定後才寫入；後端節點資料的預設時區則為 UTC。這讓「畫面已有預設值」與「設定已保存」形成落差。重現步驟與資料庫結果

這類差異會影響 AI 工作流的資料邊界。Dify 官方將排程觸發器定位為每日報告、定期清理與健康檢查的入口，支援週期設定及 cron，並可串接下游模型、代理與工具。依此用途推論，若報告在資料更新前提早啟動，即使模型正常生成，也可能使用不完整資料；工程團隊需要同時驗證啟動時間與輸入資料是否就緒。官方功能說明

同日提出的 PR #43532，打算在節點缺少時區時保存面板顯示的帳號時區，保留已存時區及唯讀模式的行為。提案也指出，舊排程若缺少時區，開啟面板並重新發布後，會改採帳號時區。因此若修補合併，部署團隊仍須檢查既有流程是否改變執行時刻，不能只把它視為顯示修正。修補提案

截至查核時，問題與 PR 均仍開啟，尚無已發布修復版本的證據。工程師可先核對節點的 timezone，以及排程表的 cron_expression、next_run_at，再以實際觸發紀錄確認；後續應追蹤維護者審查、版本發布與舊排程處理方式。