Your Nightly Job Ran Twice on the DST Switch: Making Scheduled Jobs Timezone-Safe

Description and use

A job scheduled at 01:30 in America/New_York ran twice during the fall‑back DST transition, sending duplicate emails. The fix is to separate the trigger instant (UTC) from the logical business day, convert to UTC before deduplication, and claim the date before work.

Problem

Scheduled jobs that use local wall‑clock times fire twice during the fall‑back DST transition and never during the spring‑forward transition, causing duplicate or missing work.

Outcome

The job now runs exactly once per business day, eliminating duplicate billing emails and ensuring no missed runs during DST transitions.

Workflow

• 1. Configure scheduler to use UTC or a timezone‑aware cron (e.g., CRON_TZ=America/New_York).
• 2. In the job code, compute the logical date for the current run using a helper that resolves wall‑clock times to a single UTC instant (first occurrence for ambiguous times, the jump instant for nonexistent times).
• 3. Before performing work, check if the logical date has already been claimed (e.g., via a database flag or a unique constraint).
• 4. If not claimed, claim the date and proceed; otherwise skip the run.
• 5. Store all timestamps in UTC for comparison and logging.

Evidence

Python’s zoneinfo makes the ambiguity visible through PEP 495’s fold flag… Convert to UTC before comparing and the check works.

Source

Scheduler-native timezone support is real and worth using, but it only decides when to fire… none of these platforms promise exactly‑once.

Source