To si špatně vykládáš. Databáze většinu času ukládá čas UTC. Pokud používáte PostgreSQL, může databáze ukládat čas s informacemi o časovém pásmu, ale pro praktické účely (*) je nejjednodušší si myslet, že čas ve vaší databázi je uložen jako UTC (tj. jako absolutní čas, který lze převést na libovolný čas zóna), když USE_TZ = True . Vždy představuje správný bod v čase, pro který si nemusíte pamatovat ani předpokládat žádné časové pásmo. A pokud vím, Django bude vždy ukládat čas v časovém pásmu UTC.
Když tedy načítáte objekt času pomocí select v psql , získáváte zpět čas v místním časovém pásmu vašeho počítače (časové pásmo, ve kterém používáte psql). Pokud by někdo v "America/New_York" spustil stejný výběrový dotaz, vidělo by časové razítko -04. Kdyby bylo datum 20.03.2019, viděli byste 2019-03-20 10:50:00+00 protože k tomuto datu byly Evropa/Londýn a UTC stejné.
Při načítání hodnoty DateTimeField jako python datetime.datetime objekt, Django vždy načte hodnotu UTC, protože:
To usnadňuje práci s těmito objekty datetime v kódu pythonu:Jsou to vždy časy UTC.
Pokud chcete tyto hodnoty vytisknout v PDF, použijte stejné metody, jaké používá Django pro vykreslování šablony:
from django.utils import timezone
print(timezone.template_localtime(Booking.objects.get(pk=280825).start))
Toto vykreslí datum a čas ve výchozím časovém pásmu (nebo pokud activate() jiné časové pásmo v aktuálním časovém pásmu ).
(*) Poznámka:Proč byste neměli dávat žádný význam časovému pásmu uloženému ve vaší databázi a jen o něm přemýšlet, jako by to bylo celé UTC:Pokud byste provozovali servery v různých časových pásmech, mohli byste ve skutečnosti skončit ukládáním časových razítek v různých časových pásmech . Všechny jsou stále správné (absolutní časová razítka) a lze je převést na jakékoli jiné časové pásmo. Časové pásmo použité pro ukládání tedy v zásadě postrádá smysl.