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

Django's timezone framework converts naive datetimes to UTC for storage when USE_TZ=True, assuming they belong to TIME_ZONE. During daylight-saving fall-back transitions, a local time such as 01:30 can occur twice, creating an ambiguous instant. The documentation acknowledges this overlap but does not define a deterministic resolution rule for django.utils.timezone.make_aware or model field assignment across supported versions.

For applications that schedule events, log timestamps, or store historical records, this ambiguity raises a practical design question: should the first occurrence, the second occurrence, or an error be the expected outcome? Without a documented strategy, behavior may appear inconsistent across versions or deployment environments, complicating validation and data integrity checks.

Which behavior does Django currently guarantee for ambiguous naive datetimes during DST fall-back, and how should developers configure or verify timezone conversion to avoid unintended offsets when TIME_ZONE observes daylight-saving time?