Ending Daylight Saving Time in Python – How DST Ends and Affects Datetimes in 2026

Ending Daylight Saving Time in Python – How DST Ends and Affects Datetimes in 2026

Daylight Saving Time ends each fall when clocks are set back by one hour. This “fall back” transition creates a repeated hour, which can lead to duplicate timestamps in your data. In 2026, Python’s zoneinfo module automatically handles the DST end, but understanding how it works is essential for building reliable time-based features and avoiding data duplication issues.

TL;DR — DST End Rules (2026)

• United States & Canada: First Sunday in November at 2:00 AM local time → clocks fall back to 1:00 AM
• European Union: Last Sunday in October at 1:00 AM UTC → clocks fall back to 12:00 AM
• One hour is “repeated” — the same hour occurs twice
• zoneinfo handles the transition automatically

1. How Python Handles DST End

from datetime import datetime
from zoneinfo import ZoneInfo

# New York DST end in 2026 (first Sunday in November)
ny_tz = ZoneInfo("America/New_York")

# Just before the fall back
before = datetime(2026, 11, 1, 1, 59, 59, tzinfo=ny_tz)

# During the repeated hour (1:00 AM happens twice)
repeated_1am = datetime(2026, 11, 1, 1, 0, 0, tzinfo=ny_tz)

print(before)
print(repeated_1am)

2. Real-World Data Science Examples

import pandas as pd

# Demo file so this example runs as-is (in your project this is your real export)
times = pd.date_range("2026-10-30 12:00", periods=40, freq="3h")
pd.DataFrame({
    "order_id": range(1001, 1041),
    "order_time": times.strftime("%Y-%m-%d %H:%M:%S+00:00"),
    "order_date": times.strftime("%Y-%m-%d %H:%M:%S"),
    "delivery_date": (times + pd.Timedelta(days=3)).strftime("%Y-%m-%d %H:%M:%S"),
    "amount": [round(50 + 11.5 * k, 2) for k in range(40)],
}).to_csv("sales_data.csv", index=False)

df = pd.read_csv("sales_data.csv", parse_dates=["order_time"])

# Convert to timezone-aware (zoneinfo handles DST end automatically)
df["order_time_ny"] = df["order_time"].dt.tz_convert("America/New_York")

# Detect DST end day
dst_end_day = df["order_time_ny"].dt.date == pd.Timestamp("2026-11-01").date()

print("Number of orders on DST end day:", len(df[dst_end_day]))
print("Possible duplicate hour count:", df[dst_end_day & (df["order_time_ny"].dt.hour == 1)].shape[0])

3. Best Practices in 2026

• Always use zoneinfo.ZoneInfo — it knows exactly when DST ends
• Store all internal timestamps in UTC to avoid DST-related duplication issues
• Convert to local time only for final display or user-facing reports
• Be aware that on DST end day, one hour (usually 1:00–2:00 AM) occurs twice
• Test your pipelines around DST transition dates every year

The Repeated Hour and the fold Attribute

When daylight saving time ends, the clock falls back and one local hour happens twice. In New York on 1 November 2026, the time 01:30 occurs first with offset -04:00 (daylight time) and again one hour later with offset -05:00 (standard time).

A local time alone is therefore ambiguous. Python solves this with the fold attribute: fold=0 means the first occurrence and fold=1 means the second. ZoneInfo respects fold, so the two objects get different offsets and different UTC values.

In data pipelines the safest choice is still to store UTC timestamps, which are never ambiguous, and keep local times for reports.

Worked Example: Two Different Moments with the Same Local Time

We build both occurrences of 01:30 and compare them in UTC.

from datetime import datetime, timezone
from zoneinfo import ZoneInfo

ny = ZoneInfo("America/New_York")
first = datetime(2026, 11, 1, 1, 30, tzinfo=ny, fold=0)
second = datetime(2026, 11, 1, 1, 30, tzinfo=ny, fold=1)

print(first, "->", first.astimezone(timezone.utc))
print(second, "->", second.astimezone(timezone.utc))
gap = second.astimezone(timezone.utc) - first.astimezone(timezone.utc)
print("Real gap:", gap)

Both objects print the same local time but different offsets, and their UTC values are exactly one hour apart. Without fold, logs from that hour could be merged or sorted incorrectly.

Common Mistakes

• Treating local times as unique identifiers on the DST end day.
• Ignoring fold when rebuilding datetimes from local strings.
• Deduplicating logs on local time and losing real events.
• Storing local times without their offset.

Quick Summary

• Fall back repeats one local hour.
• fold=0 is the first occurrence, fold=1 the second.
• UTC values are always unambiguous.
• Keep the offset when saving local times.

Conclusion

Understanding how Daylight Saving Time ends is just as important as knowing when it begins. In 2026, the “fall back” creates a repeated hour that can lead to duplicate timestamps in your data. Python’s zoneinfo handles this transition automatically, but you must still design your pipelines with UTC storage and proper awareness of the repeated hour to ensure accurate analytics and avoid data issues.

Next steps:

• Check your current datetime pipelines and ensure they use UTC storage and zoneinfo to correctly handle the DST end transition

Related Tutorials

• Starting Daylight Saving Time in Python – How DST Begins and Affects Datetimes in 2026
• Timezone-Aware Arithmetic in Python