Handle daylight-saving changes in a Python scheduler

A schedule stored as "01:30 every day" needs a timezone and a policy for clock changes. During an autumn daylight-saving transition, the same local time can describe two separate instants. During a spring transition, some local times do not occur.

Local clock branching into two UTC timestamps.

Show both ambiguous instants

Use an IANA zone name and timezone-aware values. This synthetic example examines an autumn transition in New York.

from datetime import datetime, timezone
from zoneinfo import ZoneInfo

zone = ZoneInfo("America/New_York")
local = datetime(2024, 11, 3, 1, 30, tzinfo=zone)

first = local.replace(fold=0).astimezone(timezone.utc)
second = local.replace(fold=1).astimezone(timezone.utc)

assert first != second
print(first.isoformat())
print(second.isoformat())

The two values correspond to different UTC instants. A scheduler must choose whether the recurring job runs at the first occurrence, the second occurrence or both. Store that decision with the schedule so a later operator can understand why the system ran when it did.

Attaching a timezone does not prove a local wall-clock value exists. For spring transitions, validate the selected local time by converting it to UTC and back. If the wall-clock components do not survive that round trip for either fold, the schedule needs a nonexistent-time policy.

Persist intent and execution separately

Keep the user's recurring intent, such as timezone and hour, separate from generated execution timestamps. The next run can be stored as UTC for comparison with the current instant. Recompute future runs according to the declared policy instead of adding a fixed number of seconds and assuming the local hour stays constant.

An execution record should identify the schedule and intended occurrence. A unique occurrence key can stop two scheduler processes from creating the same job. That does not prevent a worker from retrying an already-created task; the task still needs its own duplicate-handling policy.

Timezone data changes as governments revise local rules. Ensure the deployment has a timezone database, and record the relevant environment when reproducing a scheduling incident. On systems without the database, Python can use its separate tzdata package.

This is a scheduling demonstration, not a claim about a particular production calendar. Postzyo provides related publishing-schedule context. Python documents zoneinfo and fold and aware datetimes.