On Sunday, November 1, 2026, clocks in most of the United States move back from 2:00 a.m. to 1:00 a.m. For a Linux server, that creates a practical question: if a scheduled job is set for 1:30, can it run twice?
The answer depends on the scheduler, its implementation and the server’s time-zone settings. Some cron documentation says matching jobs can run twice in a repeated hour; Cronie documents cases where it avoids a duplicate run. A local clock change is a reason to review important jobs, not proof that one has failed.
- What Actually Happens When the Clock Goes Back?
- Why You Should Check Your Scheduler, Not Guess
- The Linux Clock-Change Checklist
- Check the server’s time basis
- Find the cron daemon and its version
- List jobs scheduled in the repeated hour
- Check for a per-table time zone
- Review systemd calendar timers separately
- Make important jobs safe to repeat
- Check backups and recovery before changing schedules
- Plan how you will verify the run
- A Hypothetical Example: A Nightly Billing Job
- What Should You Do With Your Findings?
- Sources and Related Guides
What Actually Happens When the Clock Goes Back?
In most U.S. locations that observe daylight saving time, the local clock reaches 2:00 a.m. on November 1 and returns to 1:00 a.m. The hour between 1:00 and 2:00 therefore occurs twice. The date and rule are confirmed by the U.S. National Institute of Standards and Technology. Other countries and regions change clocks on different dates or do not use seasonal clock changes.
A server follows its configured time zone, not the time zone of the person logged in from a laptop. If a VPS uses UTC, the U.S. local change does not make its UTC clock repeat an hour. Check the host before assuming the transition affects a job.
Why You Should Check Your Scheduler, Not Guess
Linux cron is not one identical implementation on every distribution. The current crontab manual on man7 says a matching job can run twice when a local time occurs more than once. The Cronie manual describes different handling for certain fixed-time jobs during a backward clock change: it avoids running the same job twice. Which guidance applies depends on the daemon and version actually installed.
A systemd timer using OnCalendar= is a real-time,
calendar-based schedule; directives such as OnBootSec=
are elapsed-time schedules. Do not apply a cron rule to both.
systemd also does not restart a service that is already active when
its timer elapses, but that alone does not prove that a task ran
exactly once on a given local date. See the
systemd timer documentation
and inspect your specific unit.
The Linux Clock-Change Checklist
These checks are read-only unless you choose to change a job. They help establish what is configured; they do not simulate the clock change or guarantee a task will succeed.
Check the server’s time basis
Run timedatectl. Note the local time, configured time zone and whether network time is synchronized.
Evidence and next action
Record: Host name, time zone and sync status. Decide: If the host uses UTC, the U.S. local clock change does not repeat an hour on that host. If its zone observes the change, continue below.
Find the cron daemon and its version
Identify the package and daemon installed by your distribution. Read its local cron(8) and crontab(5) manuals.
Evidence and next action
Record: Distribution, cron package and version. Decide: Follow that implementation’s DST section; do not assume another distribution behaves the same.
List jobs scheduled in the repeated hour
Review the current user’s crontab -l and authorized system-wide schedules. Look for jobs around 1:00–1:59 in the server’s local zone.
Evidence and next action
Record: Job owner, schedule, command and expected effect. Decide: If the command has financial, customer or destructive effects, inspect its repeat-safety before the transition.
Check for a per-table time zone
Look for CRON_TZ or other scheduler-specific time-zone settings in the relevant crontab or service configuration.
Evidence and next action
Record: The effective zone for each important job. Decide: Resolve ambiguous local scheduling with the job owner; changing the server’s global zone can affect other services.
Review systemd calendar timers separately
Use systemctl list-timers --all, then inspect relevant units with systemctl cat example.timer. Check whether they use OnCalendar= or elapsed-time directives.
Evidence and next action
Record: Timer name, schedule, target service and time zone. Decide: Use systemd-analyze calendar 'EXPRESSION' to parse a calendar expression and see its next elapse; verify behavior for your systemd version rather than inferring duplicate-run behavior from cron.
Make important jobs safe to repeat
For backups, billing, cleanup, email and data imports, ask what a second execution would do. Check whether the application uses a unique run ID, lock or duplicate guard.
Evidence and next action
Record: The owner’s repeat-safety explanation and any guard in place. Decide: Add an application-level idempotency or locking control where needed; do not rely on the clock changing only once.
Check backups and recovery before changing schedules
For a job that could overwrite or delete data, verify the last successful backup and the recovery route before editing its schedule.
Evidence and next action
Record: Most recent successful run and backup location. Decide: If recovery is uncertain, ask the service owner before making a schedule change.
Plan how you will verify the run
Know where the job writes its output and which service or application record confirms completion. Compare timestamps in UTC where possible.
Evidence and next action
Record: The expected result and log location. For systemd services, journalctl --utc -u example.service displays journal times in UTC. Decide: Compare the run record with the intended outcome, not just the scheduler’s “last triggered” time.
A Hypothetical Example: A Nightly Billing Job
Suppose a store has a cron entry scheduled for 1:30 a.m. local time that creates invoices from pending orders. Its server is configured for a U.S. time zone that changes clocks on November 1. The job is not idempotent: if it processes the same orders twice, it could create duplicate invoices.
The administrator first checks the installed cron implementation’s manual and confirms that the schedule falls inside the repeated hour. They review the script and discover it has no durable record of which orders were already invoiced. Before the transition, the application owner adds and verifies a duplicate guard in staging, then monitors the production run and invoice records.
This is a hypothetical example, not a report of a real incident or a test result. The key lesson is to trace the whole chain: clock and time zone → scheduler rule → command behavior → business result.
What Should You Do With Your Findings?
| What you found | Next action |
|---|---|
| Host uses UTC or a zone with no clock change | Document the time basis and confirm no per-job zone overrides it. |
| A critical cron job falls in the repeated hour | Check the installed daemon’s documented behavior and make the task safe to repeat. |
| A calendar systemd timer falls in that hour | Inspect the timer and target service; verify schedule interpretation for the installed systemd version. |
| Job behavior or ownership is unclear | Do not make a last-minute global time-zone change. Ask the application owner and record the decision. |
| The run completed | Verify the output or business record, then compare timestamps and logs in UTC. |
Sources and Related Guides
- NIST: Daylight Saving Time Rules — 2026 U.S. clock-change date and local-time rule.
- Linux crontab manual — cron schedule matching and repeated/nonexistent local times.
- Cronie manual — implementation-specific handling of clock changes.
- systemd.timer documentation and systemd.time documentation — calendar and elapsed-time timer behavior.
- journalctl manual — UTC output option.
- Cron vs systemd Timers: How Scheduled Tasks Work on Linux — compare the two scheduling models.
- journalctl Explained: How to Read Linux Service Logs and Find Errors — inspect service events.
- Your First Hour on a Linux Server — check time zone and synchronization on a VPS.
The clock-change date and scheduler references were checked October 31, 2026. Cron behavior varies by implementation and version. This guide does not report a live test or a confirmed incident.
