Handling Timezone Changes in Timers

Understand how systemd handles daylight savings and timezone shifts in scheduling.

In this lesson, you will learn how systemd timers behave when the underlying system clock shifts due to Daylight Saving Time (DST) or timezone modifications.

The Problem with Wall-Clock Scheduling

When you define a timer using OnCalendar=*-*-* 03:00:00, you are specifying a "wall-clock" time. In a standard scheduling system, this creates ambiguity: what happens when a clock skips forward (losing an hour) or falls back (repeating an hour)?

Unlike traditional cron jobs, which often struggle with these transitions, systemd timers are designed to be "monotonic-aware" while respecting the system's local time configuration.

How Systemd Handles the Transition

systemd uses the RTC (Real-Time Clock) and the system’s timezone database (/etc/localtime) to calculate the next trigger.

Spring Forward (DST start): If you schedule a task for 02:30 AM, but the clock skips from 02:00 to 03:00, the task will not execute at that specific moment because that wall-clock time technically never existed. systemd recognizes the gap and will trigger the task at the next valid time (typically 03:00:00).
Fall Back (DST end): If the clock repeats an hour (e.g., from 01:00 back to 01:00), systemd treats the first occurrence as the active trigger point. It does not blindly run the task twice unless your configuration explicitly defines multiple triggers.

Implementation Best Practice

To ensure your automation remains predictable regardless of timezone shifts, always verify your timezone settings using timedatectl. You can view your current configuration with:

timedatectl show --property=Timezone

If your tasks are critical and must run at an absolute interval rather than a specific wall-clock time, you should favor OnUnitActiveSec= or OnBootSec= over OnCalendar=.

For example, a timer defined as:

[Timer]
OnCalendar=*-*-* 02:00:00

is bound to the local clock. If you require a task to run exactly every 24 hours regardless of DST, use:

[Timer]
OnUnitActiveSec=24h

This ensures that the "time-distance" between executions remains constant, insulating your automation pipeline from the complexities of regional clock adjustments.

Key Takeaway: Systemd timers linked to OnCalendar follow the local system clock, skipping or shifting during DST transitions, while OnUnitActiveSec provides a drift-free interval immune to timezone changes.