Difyコミュニティがスケジュールのタイムゾーン修正を提案、新しいワークフローでローカル時刻表示のままUTC実行となる可能性

Difyのスケジュールトリガーについて、画面表示と実際の実行時刻が一致しないというコミュニティ報告が寄せられた。10月5日に投稿された事例では、Dockerセルフホスト版1.17.1でSchedule Triggerを追加し、設定を変更せずにワークフローを公開すると、パネルにはアカウントのタイムゾーンが表示される一方、保存されたノードデータにはtimezoneが含まれず、バックエンドがUTCを採用していた。問題はトリガー設定の永続化に関係しており、影響範囲の全容は上流での確認を待っている。問題報告

報告者はニューヨークのアカウントを使って実例を示した。画面には毎日午前0時に実行と表示され、次回実行時刻は10月6日04:00 UTCと予想されるが、データベースのスケジュール計画には同日00:00 UTCと記録され、4時間早まっていた。原因分析によると、フロントエンドはアカウントのタイムゾーンを使って表示値を補完するが、設定を書き込むのはユーザーが設定を編集した場合に限られる。一方、バックエンドのノードデータではタイムゾーンのデフォルトがUTCとなっている。このため、「画面にデフォルト値が表示されている」ことと「設定が保存されている」ことに食い違いが生じる。再現手順とデータベースの結果

このようなずれは、AIワークフローが扱うデータの境界に影響する。Difyはスケジュールトリガーを、日次レポート、定期的なクリーンアップ、ヘルスチェックなどの起点として位置づけている。周期設定とcronに対応し、後続のモデル、エージェント、ツールにも接続できる。この用途から考えると、データ更新前にレポート生成が始まった場合、モデルが正常に出力しても不完全なデータを使う可能性がある。エンジニアリングチームは、起動時刻と入力データの準備状況の両方を検証する必要がある。公式機能説明

同日提出されたPR #43532は、ノードにタイムゾーンがない場合、パネルに表示されているアカウントのタイムゾーンを保存することを提案している。保存済みのタイムゾーンと読み取り専用モードの動作は維持する。提案ではまた、タイムゾーンが未設定の古いスケジュールは、パネルを開いて再公開するとアカウントのタイムゾーンを使うようになると説明している。そのため、修正がマージされた場合、運用チームは既存フローの実行時刻が変わらないか確認する必要がある。単なる表示修正として扱うべきではない。修正提案

確認時点では、問題報告とPRはいずれもオープンで、修正を含むリリース済みバージョンの証拠はない。エンジニアはまずノードのtimezoneと、スケジュールテーブルのcron_expression、next_run_atを確認し、実際のトリガー記録とも照合できる。今後はメンテナーのレビュー、バージョンのリリース、既存スケジュールの扱いを追跡する必要がある。