You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature]: Time zone support for fixed-time scheduled tasks
#17165
A fixed_time scheduled task (for example "every day at 06:00") runs on the server machine's local clock. The orchestrator tool documents it as "a fixed local wall-clock time". There is no way to say which time zone the time is meant in.
That breaks down when the server is not in the user's time zone, which is common with a remote or tunnelled environment, a VPS, or a container that defaults to UTC:
I want a task at 00:00, 06:00, 12:00 and 18:00 Rome time, but the server runs in UTC. I had to enter 22:00, 04:00, 10:00 and 16:00 (Rome is UTC+2 right now) and rename the tasks to say so.
Daylight saving makes this worse. When Rome leaves summer time on 2026-10-25, those UTC offsets silently shift by an hour. Nothing warns the user, and every task has to be edited by hand twice a year.
The tool never reports which time zone the server is using, so the offset has to be worked out by hand.
I searched issues, PRs and discussions for "timezone" / "time zone" in scheduled tasks and did not find an existing report. #15565 (custom recurrence) and #6748 (scheduled prompts) are the closest, but neither covers time zones.
Proposed solution
Add an optional timeZone field to the fixed_time schedule, as an IANA name such as Europe/Rome.
When it is set, timeOfDay and weekdays are evaluated in that zone, including DST changes.
When it is omitted, behaviour stays exactly as today (server local time), so existing tasks are unaffected.
Clients default the field to the user's own zone when creating a task, and show the zone next to the time.
At minimum, whether or not the field is added, the task list and the tool output could show the server's time zone so users can tell what "06:00" means.
Alternatives considered
Keep server-local time and document it. Works, but users have to do UTC-offset arithmetic and fix tasks at every DST change.
Let interval tasks start from an anchor time. Avoids zones, but drifts and can't express "weekdays at 09:00".
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Problem or use case
A
fixed_timescheduled task (for example "every day at 06:00") runs on the server machine's local clock. The orchestrator tool documents it as "a fixed local wall-clock time". There is no way to say which time zone the time is meant in.That breaks down when the server is not in the user's time zone, which is common with a remote or tunnelled environment, a VPS, or a container that defaults to UTC:
I searched issues, PRs and discussions for "timezone" / "time zone" in scheduled tasks and did not find an existing report. #15565 (custom recurrence) and #6748 (scheduled prompts) are the closest, but neither covers time zones.
Proposed solution
Add an optional
timeZonefield to thefixed_timeschedule, as an IANA name such asEurope/Rome.timeOfDayandweekdaysare evaluated in that zone, including DST changes.Alternatives considered
intervaltasks start from an anchor time. Avoids zones, but drifts and can't express "weekdays at 09:00".Related
timeZonefield would apply to each of those run times too.All reactions