Django timezone.make_aware lacks deterministic handling for ambiguous DST fall-back times

Answer

Django does not guarantee a deterministic, version-stable outcome for ambiguous naive datetimes during DST fall-back. The documentation acknowledges that local times can be ambiguous, but it does not define a documented resolution rule for django.utils.timezone.make_aware or for implicit conversion on model fields with USE_TZ=True. Behavior can differ across Django releases, between pytz and zoneinfo backends, and across hosts with different tzdata.

Confirmed fact: no stable contract is provided. Confirmed fact: the result is not guaranteed to be the same across releases, backends, or tzdata versions.

Likely explanation

Likely explanation from model knowledge: with a pytz timezone, make_aware historically delegates to pytz.timezone.localize with a fixed is_dst flag. That makes the result appear deterministic, typically selecting standard time, the second occurrence of the fall-back hour, but the exact flag and its effect are implementation details and have changed between Django versions.

Likely explanation from model knowledge: with a zoneinfo datetime.timezone backend, which Django prefers on recent Python versions, make_aware builds an aware datetime via replace and does not set the fold attribute. Python then defaults fold=0, which corresponds to the first occurrence of an ambiguous wall time, unless the caller explicitly sets fold.

Steps to avoid unintended offsets for this case

1. Identify the active backend. Check whether the active timezone is a pytz instance or a zoneinfo datetime.timezone. This determines which code path make_aware uses.
2. Verify the current resolution with a reproducible test for your configured TIME_ZONE. Create a known ambiguous wall time in the fall-back overlap, call make_aware, and log the resulting UTC offset and, for zoneinfo, the fold attribute. Compare it to both possible offsets for the transition.
3. Treat naive input as an error condition for ambiguous times. Do not rely on implicit resolution. Require explicit disambiguation before calling make_aware, e.g., by rejecting naive datetimes that fall in a DST overlap or by requiring the caller to supply is_dst for pytz or fold for zoneinfo.
4. Audit code paths that accept naive datetimes from users, forms or APIs and ensure they are either rejected or disambiguated before make_aware is invoked. Model field assignment with USE_TZ=True will call make_aware implicitly for naive datetimes, inheriting the same ambiguity without raising an error by default.

One missing diagnostic detail that changes the recommendation: which TIME_ZONE is configured in your project and whether your runtime is using pytz or zoneinfo for that zone. The exact safe disambiguation strategy depends on that backend.