Je interpreteert dit verkeerd. De database slaat meestal een UTC-tijd op. Als u PostgreSQL gebruikt, kan de database een tijd opslaan met tijdzone-informatie, maar voor praktische doeleinden (*) is het het gemakkelijkst om te denken dat de tijd in uw db wordt opgeslagen als UTC (d.w.z. als een absolute tijd die kan worden omgezet naar elk tijdstip zone) wanneer USE_TZ = True . Het vertegenwoordigt altijd een correct tijdstip waarvoor u geen tijdzone hoeft te onthouden of aan te nemen. En voor zover ik weet, zal Django de tijd altijd als tijdbewust opslaan in de UTC-tijdzone.
Dus wanneer u het tijdobject ophaalt met select in psql , krijgt u de tijd terug in de lokale tijdzone van uw computer (de tijdzone waarin u psql uitvoert). Als iemand in "Amerika/New_York" dezelfde selectiequery zou uitvoeren, zou ze een tijdstempel van -04 zien. Als de datum 20-03-2019 was geweest, had je 2019-03-20 10:50:00+00 gezien want op die datum waren Europa/Londen en UTC hetzelfde.
Bij het ophalen van de waarde van een DateTimeField als een python datetime.datetime object, haalt Django altijd de UTC-waarde op, omdat:
Dit maakt het gemakkelijker om met deze datetime-objecten in uw python-code te werken:het zijn altijd UTC-tijden.
Als u deze waarden in een PDF wilt afdrukken, gebruikt u dezelfde methoden die Django gebruikt voor de sjabloonweergave:
from django.utils import timezone
print(timezone.template_localtime(Booking.objects.get(pk=280825).start))
Dit geeft de datetime weer in de standaard tijdzone (of als je activate() een andere tijdzone, in de huidige tijdzone ).
(*) Opmerking:waarom zou u geen betekenis geven aan de tijdzone die in uw db is opgeslagen en er gewoon over nadenken alsof het allemaal UTC is:als u servers in verschillende tijdzones zou draaien, zou u uiteindelijk tijdstempels in verschillende tijdzones kunnen opslaan . Ze zijn nog steeds allemaal correct (absolute tijdstempels) en kunnen worden geconverteerd naar elke andere tijdzone. Dus eigenlijk is de tijdzone die gebruikt wordt om op te slaan zinloos.