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

Описание и применение

Скрипт, запланированный на 01:30 в зоне America/New_York, запускался дважды во время перехода на зимнее время, отправляя дублирующие письма. Решение – разделить триггерное время (UTC‑инстант) и логическую дату (рабочий период), конвертировать в UTC перед проверкой дублирования и фиксировать дату до выполнения работы.

Задача

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.

Результат

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

Рабочий процесс

• 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.

Доказательства

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

Источник

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

Источник