October 31, 2025

The Day the Clock Duplicated an Hour: A Guide to Fall Back

We “time-travel” this Sunday, Nov 2. Keep servers happy during the duplicated 1–2 AM hour with a playful primer, a 5-minute readiness checklist, and quick post-change checks.

The day the clock duplicated an hour

“The Mystery of the Two 1:37 AMs”
Imagine a job named PumpkinSpiceReport scheduled for 1:37 AM local. On fall back night, it runs at the first 1:37, then time rewinds, and it cheerfully runs again at the second 1:37. If your pipeline isn’t idempotent, you’ve just brewed a double-shot of pumpkin chaos. Don’t be that latte.

Twice a year, we do casual time travel. In fall, we get the “bonus hour”—which sounds great until your backup runs twice, logs get out of order, and a job scheduled at 1–2 AM runs… at two different 1:30 AMs. This quick guide keeps the whimsy—and the wheels on.

What actually happens:
At 2:00 AM local time on Sunday, November 2, 2025, the clock jumps back to 1:00 AM. The 1:00–2:00 AM hour happens twice. Anything scheduled by local time in that hour may run twice; anything measuring durations/SLAs may see weirdness.

5-minute DST readiness checklist (do this today)

1) Confirm the box knows its timezone & syncs time

Linux (systemd):

timedatectl

1
2

timedatectl

Ensure Time zone is correct and System clock synchronized: yes.
Windows: Settings → Time & Language → Date & time. Make sure Set time automatically and Set time zone automatically are on (servers often fix the zone; that’s fine).
NTP/chrony: one of these should be active (systemctl status chronyd or systemctl status systemd-timesyncd).

2) Make sure tzdata isn’t ancient

Debian/Ubuntu: apt list --installed tzdata
RHEL/Alma/Rocky: rpm -q tzdata
Update if outdated: sudo apt-get update && sudo apt-get install --only-upgrade tzdata (or sudo dnf update tzdata)

3) Hunt for jobs between 1:00–2:00 AM local

Cron (Linux):

sudo crontab -l sudo ls /etc/cron.d/ | xargs -I{} sudo cat /etc/cron.d/{}

1
2
3

sudo crontab -l
sudo ls /etc/cron.d/ | xargs -I{} sudo cat /etc/cron.d/{}

Look for 1 * * * * or explicit 1:xx. If it must run once, run it at 01:30 UTC or move to 02:30 local just for Sunday.
Windows Task Scheduler: filter tasks Next Run Time for the 1–2 AM window.

4) Check backups, batch, and ETL

Verify backup windows don’t assume a 60-minute hour. If the vendor has a “run once at wall-clock time” switch, turn it on for Sunday.

5) Check app/runtime layers

Java: ensure latest TZDB (comes via JDK updates).
.NET / Python / Node: prefer UTC in code; don’t DIY DST math.
Docker containers: base images may ship stale tzdata; rebuild or apk/apt upgrade tzdata in the image.

6) Databases & logs

Prefer UTC timestamps for storage.
Postgres: SHOW timezone; (consider UTC)
MySQL/MariaDB: SELECT @@global.time_zone, @@session.time_zone;
Make sure log shippers handle duplicate timestamps gracefully.

7) Monitoring & alerts

Temporarily widen alert windows/thresholds for the changeover hour to avoid noise.

After the fall back: 5 quick sanity checks (Sunday morning)

date / time shows correct local time.
journalctl --since "2025-11-02 00:30" --until "2025-11-02 03:30" shows no clock-skew errors.
Backups: last run time is sane and not duplicated unless intended.
Batch/ETL: downstream counts align with a normal Sunday.
Dashboards: no gaps/overages around 1–2 AM.

Pro tips to avoid DST drama forever

Schedule in UTC whenever possible; display in local time for humans.
Avoid 1:00–2:00 AM local for recurring jobs. Choose 03:15 local or a UTC time outside local DST shifts.
Idempotency + de-dupe: Make jobs safe to run twice.
Log in UTC, annotate with local offset only at render time.
Infra as code: bake correct TZ and tzdata updates into images/AMIs.