मैं कोई अजगर या Django गुरु नहीं हूं, इसलिए शायद कोई मुझसे बेहतर जवाब दे सकता है। लेकिन मैं वैसे भी इसका अनुमान लगाऊंगा।
आपने कहा था कि आप इसे एक Django DateTimeField . में संग्रहीत कर रहे थे , जो आपके द्वारा संदर्भित दस्तावेज़
के अनुसार , इसे Python datetime . के रूप में संग्रहीत करता है ।
datetime के दस्तावेज़ देख रहे हैं
, मुझे लगता है कि कुंजी "बेवकूफ" और "जागरूक" मूल्यों के बीच अंतर को समझ रही है।
और फिर आगे शोध करते हुए, मुझे यह उत्कृष्ट संदर्भ
मिला। . सुनिश्चित करें कि दूसरा खंड, "निष्पक्ष और जागरूक डेटाटाइम ऑब्जेक्ट्स" पढ़ें। इससे थोड़ा सा संदर्भ मिलता है कि इसमें से कितना Django द्वारा नियंत्रित किया जा रहा है। मूल रूप से, USE_TZ = true . सेट करके , आप Django को जागरूक . का उपयोग करने के लिए कह रहे हैं बेवकूफ . के बजाय datetimes वाले।
तो फिर मैंने आपके प्रश्न की ओर मुड़कर देखा। आपने कहा था कि आप निम्न कार्य कर रहे हैं:
dt = datetime.fromtimestamp(secs)
dt = dt.replace(tzinfo=utc)
fromtimestamp को देख रहे हैं फ़ंक्शन दस्तावेज़ीकरण, मुझे यह पाठ का बिट मिला:
तो मुझे लगता है कि आप यह कर सकते हैं:
dt = datetime.fromtimestamp(secs, tz=utc)
फिर फिर, उस फ़ंक्शन के ठीक नीचे, दस्तावेज़ utcfromtimestamp . दिखाते हैं समारोह, तो शायद यह होना चाहिए:
dt = datetime.utcfromtimestamp(secs)
मैं अजगर के बारे में यह जानने के लिए पर्याप्त नहीं हूं कि ये समकक्ष हैं या नहीं, लेकिन आप कोशिश कर सकते हैं और देख सकते हैं कि क्या कोई फर्क पड़ता है।
उम्मीद है कि इनमें से एक से फर्क पड़ेगा। यदि नहीं, तो कृपया मुझे बताएं। मैं जावास्क्रिप्ट और नेट में दिनांक/समय से अच्छी तरह परिचित हूं, लेकिन मुझे हमेशा इस बात में दिलचस्पी है कि ये बारीकियां अन्य प्लेटफार्मों, जैसे कि पायथन में अलग तरह से कैसे चलती हैं।
अपडेट करें
प्रश्न के MySQL भाग के संबंध में, this fiddle पर एक नज़र डालें। ।
CREATE TABLE foo (`date` DATETIME);
INSERT INTO foo (`date`) VALUES (FROM_UNIXTIME(1371131402));
SET TIME_ZONE="+00:00";
select `date`, UNIX_TIMESTAMP(`date`) from foo;
SET TIME_ZONE="+01:00";
select `date`, UNIX_TIMESTAMP(`date`) from foo;
परिणाम:
DATE UNIX_TIMESTAMP(`DATE`)
June, 13 2013 13:50:02+0000 1371131402
June, 13 2013 13:50:02+0000 1371127802
ऐसा लगता है कि UNIX_TIMESTAMP . का व्यवहार फ़ंक्शन वास्तव में MySQL TIME_ZONE से प्रभावित होता है स्थापना। यह इतना आश्चर्यजनक नहीं है, क्योंकि यह प्रलेखन में है। आश्चर्य की बात यह है कि datetime . का स्ट्रिंग आउटपुट सेटिंग की परवाह किए बिना समान UTC मान है।
यहाँ मुझे लगता है कि हो रहा है। UNIX_TIMESTAMP . के लिए डॉक्स में फ़ंक्शन, यह कहता है:
ध्यान दें कि यह नहीं कहता है कि यह एक DATETIME हो सकता है - यह कहता है कि यह एक DATETIME हो सकता है स्ट्रिंग . इसलिए मुझे लगता है कि फ़ंक्शन में पारित होने से पहले वास्तविक मान को एक स्ट्रिंग में परिवर्तित किया जा रहा है।
तो अब इस अपडेटेड फिडल को देखें। जो स्पष्ट रूप से परिवर्तित होता है।
SET TIME_ZONE="+00:00";
select `date`, convert(`date`, char), UNIX_TIMESTAMP(convert(`date`, char)) from foo;
SET TIME_ZONE="+01:00";
select `date`, convert(`date`, char), UNIX_TIMESTAMP(convert(`date`, char)) from foo;
परिणाम:
DATE CONVERT(`DATE`, CHAR) UNIX_TIMESTAMP(CONVERT(`DATE`, CHAR))
June, 13 2013 13:50:02+0000 2013-06-13 13:50:02 1371131402
June, 13 2013 13:50:02+0000 2013-06-13 13:50:02 1371127802
आप देख सकते हैं कि जब यह कैरेक्टर डेटा में परिवर्तित होता है, तो यह ऑफसेट को हटा देता है। तो निश्चित रूप से, अब यह समझ में आता है कि जब UNIX_TIMESTAMP इस मान को इनपुट के रूप में लेता है, यह स्थानीय समय क्षेत्र सेटिंग मान रहा है और इस प्रकार एक अलग यूटीसी टाइमस्टैम्प प्राप्त कर रहा है।
सुनिश्चित नहीं है कि यह आपकी मदद करेगा या नहीं। आपको और अधिक खुदाई करने की आवश्यकता है कि कैसे Django पढ़ने और लिखने दोनों के लिए MySQL को कॉल कर रहा है। क्या यह वास्तव में UNIX_TIMESTAMP . का उपयोग करता है समारोह? या यह वही था जो आपने परीक्षण में किया था?
