Dify Community Proposes Scheduling Timezone Fix; New Workflows May Show Local Time but Run on UTC

A community report says Dify’s schedule trigger can display a time in the interface that differs from its actual execution time. The case, submitted on October 5, used self-hosted Dify 1.17.1 running in Docker: after adding a Schedule Trigger and publishing the workflow without changing its settings, the panel showed the account’s timezone, but the saved node data had no timezone field. The backend therefore used UTC. The issue concerns persistence of trigger settings, and the full scope of its impact has yet to be confirmed upstream. Issue report

The reporter demonstrated the issue with a New York account: the interface showed a daily run at midnight, so the expected next run was 04:00 UTC on October 6. But the schedule record in the database showed 00:00 UTC that day, four hours earlier. The reporter’s root-cause analysis says the frontend fills in the displayed value using the account’s timezone, but only writes it after the user edits the settings; the backend node data defaults to UTC. This creates a gap between “a default value is displayed” and “the setting has been saved.” Reproduction steps and database results

This kind of discrepancy can affect the data boundaries of AI workflows. Dify describes the schedule trigger as an entry point for daily reports, periodic cleanup, and health checks. It supports recurring schedules and cron, and can connect to downstream models, agents, and tools. From these use cases, it follows that if a report starts before its data has been updated, it may use incomplete data even if the model generates normally. Engineering teams need to verify both the start time and whether the input data is ready. Official feature description

PR #43532, proposed the same day, would save the timezone displayed in the panel when a node has no timezone, while preserving the behavior for an already saved timezone and for read-only mode. The proposal also notes that if an older schedule has no timezone, opening the panel and republishing it will cause it to use the account’s timezone. If the fix is merged, deployment teams will still need to check whether existing workflows change their execution times; they should not treat this solely as a display correction. Proposed fix

As of the time of review, both the issue and PR remain open, and there is no evidence of a released fix. Engineers can first check the node’s timezone and the schedule table’s cron_expression and next_run_at, then confirm against actual trigger records. They should continue tracking maintainer review, the release, and how existing schedules will be handled.