Du tolker det forkert. Databasen gemmer en UTC-tid det meste af tiden. Hvis du bruger PostgreSQL, kan databasen gemme et tidspunkt med tidszoneinfo, men af praktiske årsager (*) er det nemmest bare at tro, at tiden i din db er gemt som UTC (dvs. som et absolut tidspunkt, der kan konverteres til et hvilket som helst tidspunkt) zone), når USE_TZ = True . Det repræsenterer altid et korrekt tidspunkt, for hvilket du ikke behøver at huske eller antage nogen tidszone. Og så vidt jeg ved, vil Django altid gemme tiden som tidsbevidst i UTC-tidszonen.
Så når du henter tidsobjektet ved hjælp af select i psql , får du tiden tilbage i maskinens lokale tidszone (den tidszone, hvor du kører psql). Hvis nogen i "America/New_York" ville køre den samme udvalgte forespørgsel, ville hun se et -04 tidsstempel. Havde datoen været 2019-03-20, ville du have set 2019-03-20 10:50:00+00 fordi på den dato var Europa/London og UTC de samme.
Når du henter værdien af et DateTimeField som en python datetime.datetime objekt, henter Django altid UTC-værdien, fordi:
Dette gør det nemmere at arbejde med disse datetime-objekter i din python-kode:De er altid UTC-tider.
Hvis du vil udskrive disse værdier i en PDF, skal du bruge de samme metoder, som Django bruger til skabelongengivelsen:
from django.utils import timezone
print(timezone.template_localtime(Booking.objects.get(pk=280825).start))
Dette gengiver datetime i standardtidszonen (eller hvis du activate() en anden tidszone i den aktuelle tidszone ).
(*) Bemærk:Hvorfor du ikke skal give nogen mening til den tidszone, der er gemt i din db og bare tænke på det, som om det hele er UTC:Hvis du skulle køre servere i forskellige tidszoner, kan du faktisk ende med at gemme tidsstempler i forskellige tidszoner . De er stadig alle korrekte (absolutte tidsstempler) og kan konverteres til enhver anden tidszone. Så dybest set er den tidszone, der bruges til at gemme, meningsløs.