Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Rundeck DST handling

Open
  • Is something wrong?
#1,993 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
documentation

Research direction

The claims concern how Rundeck's Quartz cron triggers handle DST, and the source page is the job-creation section of the manual linked in the issue (creating-jobs.html). Start by reading that section, then set up a job in a DST-observing timezone and check what happens at the spring-forward and fall-back transitions. Done means each claim is confirmed or corrected with observed results, and the documentation gets a short DST best-practices note.

Written by the indexing model from the issue text.

Description

Rundeck Version

5.17

Describe the issue

We dont have current information related to the DTS handling on scheduled jobs. Forrest shared the following input on this:

Rundeck schedules jobs with Quartz cron triggers. Each fire time is worked out from wall-clock time in the job’s timezone. That’s the timezone set on the job’s schedule, or the server’s JVM timezone if the job doesn’t set one.

  1. Spring-forward (02:00 jumps to 03:00)

A job set for a time inside the skipped hour, such as 02:30, doesn’t run at 02:30 that day because that time never happens.
Quartz uses lenient Java calendar math, so the time normally shifts forward and the job runs once, shortly after the change (e.g. at 03:30). It isn’t silently dropped. This is the case I’d most want confirmed with a quick test before quoting it to the customer.
This isn’t a misfire. Misfire rules only apply when the scheduler was down or had no free threads at the fire time.
Jobs that repeat often (every 15 minutes, every hour) simply have no runs during the missing hour.
2. Fall-back (03:00 goes back to 02:00)

A once-a-day job at 02:30 runs once, on the first 02:30. After it fires, Quartz looks for the next match after that moment and lands on the next day, not the second 02:30.
Jobs that repeat often, like 0 */15 * * * ? or hourly, follow the wall clock, so they can run twice during the repeated hour.
Other questions

Version dependence: This has been stable across Rundeck/RBA versions because the Quartz scheduling logic hasn’t changed in this area. No known version-specific differences.
Configuration that changes the behavior:
The job’s timezone is the main control. Setting a job to UTC, or any zone without DST, removes the problem completely.
The server JVM timezone (-Duser.timezone) is used for any job that doesn’t set its own.
Misfire settings don’t change DST handling.

Best practices:
Avoid scheduling jobs between roughly 01:00 and 03:00 local time in zones that observe DST.
Or set those jobs’ schedule timezone to UTC.
Make jobs safe to run twice if they repeat often across the fall-back hour.
Turn off “allow multiple executions” if a duplicate run would cause problems.

Timezone-specific considerations:
The logic is the same in every zone. What differs is when each zone changes and by how much: US and EU switch on different dates, the southern hemisphere switches in the opposite direction, and Lord Howe Island shifts by only 30 minutes.
Rundeck relies on the JVM’s timezone database, so keeping Java up to date matters when a country changes its DST rules.

Source page

https://docs.rundeck.com/docs/manual/jobs/creating-jobs.html#creating-a-job

Dominant language
JavaScript
Stars
93
Forks
177
Avg merge
2d 8h
Merged PRs (30d)
28

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rundeck/docs

All issues in rundeck/docs

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.