Źle to interpretujesz. Baza danych przez większość czasu przechowuje czas UTC. Jeśli używasz PostgreSQL, baza danych może przechowywać czas z informacją o strefie czasowej, ale ze względów praktycznych (*) najłatwiej jest po prostu pomyśleć, że czas w twojej bazie danych jest przechowywany jako UTC (tj. jako czas bezwzględny, który można przekonwertować na dowolny czas strefa) gdy USE_TZ = True . Zawsze reprezentuje właściwy moment w czasie, dla którego nie musisz pamiętać ani zakładać żadnej strefy czasowej. O ile mi wiadomo, Django zawsze przechowuje czas w strefie czasowej UTC.
Więc kiedy pobierasz obiekt czasu za pomocą select w psql , wracasz do lokalnej strefy czasowej twojego komputera (strefy czasowej, w której używasz psql). Jeśli ktoś w „Ameryka/Nowy_Jork” uruchomiłby to samo zapytanie wybierające, zobaczyłby znacznik czasu -04. Gdyby data była 2019-03-20, zobaczyłbyś 2019-03-20 10:50:00+00 ponieważ w tym dniu Europa/Londyn i UTC były takie same.
Podczas pobierania wartości DateTimeField jako python datetime.datetime obiekt, Django zawsze pobiera wartość UTC, ponieważ:
Ułatwia to pracę z tymi obiektami datetime w kodzie Pythona:zawsze są to czasy UTC.
Jeśli chcesz wydrukować te wartości w pliku PDF, użyj tych samych metod, których Django używa do renderowania szablonu:
from django.utils import timezone
print(timezone.template_localtime(Booking.objects.get(pk=280825).start))
To renderuje datę i godzinę w domyślnej strefie czasowej (lub jeśli activate() inna strefa czasowa, w bieżącej strefie czasowej ).
(*) Uwaga:Dlaczego nie powinieneś nadawać żadnego znaczenia strefie czasowej zapisanej w twojej bazie danych i po prostu myśleć o tym tak, jakby to wszystko było UTC:Jeśli miałbyś uruchamiać serwery w różnych strefach czasowych, możesz faktycznie zapisać znaczniki czasowe w różnych strefach czasowych . Wszystkie są nadal poprawne (bezwzględne sygnatury czasowe) i można je przekonwertować na dowolną inną strefę czasową. Więc w zasadzie strefa czasowa używana do zapisywania jest bez znaczenia.
