Django and PostgreSQL: naive datetime conversion at the application-database boundary

Answer

When USE_TZ=True, Django treats a naive datetime submitted via a model form as local time in the active TIME_ZONE, makes it timezone‑aware, converts it to UTC, and passes that UTC value to the psycopg2 adapter, which stores it as a timestamptz in PostgreSQL.

Confirmed facts

• Django's ORM receives the naive datetime from the form and calls timezone.make_aware(value, timezone.get_current_timezone()).
• The aware datetime is then converted to UTC with timezone.localtime(value, timezone.utc) before being handed to the database adapter.
• Psycopg2 sends the UTC timestamptz to PostgreSQL; the database stores it internally as UTC and does not reinterpret it.
• During DST gaps or ambiguous times, make_aware raises a ValueError unless the caller supplies an explicit is_dst flag, so the form validation will reject such input.
• Changing settings.TIME_ZONE after data is stored does not alter existing UTC values; newly submitted naive datetimes are interpreted with the new zone, while existing rows are displayed according to the current active zone when read.

Steps for this case

1. Form submission yields a naive datetime object.
2. Django's timezone middleware activates settings.TIME_ZONE as the current timezone.
3. The ORM calls timezone.make_aware(naive_dt, timezone.get_current_timezone()) → aware datetime in the local zone.
4. It then converts to UTC: timezone.localtime(aware_dt, timezone.utc).
5. The resulting UTC aware datetime is passed to psycopg2, which writes a timestamptz value equal to that UTC instant.
6. PostgreSQL stores the value internally as UTC; retrieving it later and converting with the current active zone yields the appropriate local representation.