आप इसकी गलत व्याख्या कर रहे हैं। डेटाबेस अधिकांश समय UTC समय संग्रहीत करता है। यदि आप PostgreSQL का उपयोग करते हैं, तो डेटाबेस समय क्षेत्र की जानकारी के साथ एक समय संग्रहीत कर सकता है, लेकिन व्यावहारिक उद्देश्यों (*) के लिए यह सोचना सबसे आसान है कि आपके डीबी में समय यूटीसी के रूप में संग्रहीत है (यानी एक पूर्ण समय के रूप में जिसे किसी भी समय परिवर्तित किया जा सकता है) ज़ोन) जब USE_TZ = True . यह हमेशा एक सही समय बिंदु का प्रतिनिधित्व करता है जिसके लिए आपको किसी समय क्षेत्र को याद रखने या ग्रहण करने की आवश्यकता नहीं होती है। और जहाँ तक मुझे पता है, Django हमेशा UTC टाइमज़ोन में समय-जागरूक के रूप में समय संग्रहीत करेगा।
इसलिए जब आप select . का उपयोग करके टाइम ऑब्जेक्ट प्राप्त कर रहे हों psql . में , आप अपनी मशीन के स्थानीय समय क्षेत्र (समय क्षेत्र जहां आप psql चला रहे हैं) में समय वापस पा रहे हैं। यदि "अमेरिका/न्यू_यॉर्क" में कोई व्यक्ति समान चयनित क्वेरी चलाएगा, तो उसे -04 टाइमस्टैम्प दिखाई देगा। अगर तारीख 2019-03-20 होती, तो आपने 2019-03-20 10:50:00+00 देखा होता क्योंकि उस तारीख को, यूरोप/लंदन और यूटीसी समान थे।
DateTimeField का मान प्राप्त करते समय एक अजगर के रूप में datetime.datetime ऑब्जेक्ट, Django हमेशा UTC मान प्राप्त करता है, क्योंकि:
इससे आपके पायथन कोड में इन डेटाटाइम ऑब्जेक्ट्स के साथ काम करना आसान हो जाता है:वे हमेशा यूटीसी समय होते हैं।
यदि आप इन मानों को एक पीडीएफ में प्रिंट करना चाहते हैं, तो उसी तरीके का उपयोग करें जो Django टेम्प्लेट रेंडरिंग के लिए उपयोग करता है:
from django.utils import timezone
print(timezone.template_localtime(Booking.objects.get(pk=280825).start))
यह डिफ़ॉल्ट टाइमज़ोन में डेटाटाइम प्रस्तुत करता है (या यदि आप activate() वर्तमान समय क्षेत्र . में एक अलग समय क्षेत्र )।
(*) नोट:आपको अपने डीबी में सहेजे गए टाइमज़ोन को कोई अर्थ क्यों नहीं देना चाहिए और इसके बारे में सोचें जैसे कि यह सब यूटीसी है:यदि आप विभिन्न टाइमज़ोन में सर्वर चलाते हैं, तो आप वास्तव में अलग-अलग टाइमज़ोन में टाइमस्टैम्प सहेज सकते हैं . वे अभी भी सभी सही हैं (पूर्ण टाइमस्टैम्प) और किसी भी अन्य टाइमज़ोन में परिवर्तित किया जा सकता है। तो मूल रूप से बचत के लिए उपयोग किया जाने वाला समय क्षेत्र अर्थहीन है।
