मैंने इसे अपने उद्देश्यों के लिए समझ लिया है। मैंने जो सीखा उसे संक्षेप में बताऊंगा (क्षमा करें, ये नोट वर्बोज़ हैं; ये मेरे भविष्य के रेफ़रल के लिए उतने ही हैं जितने किसी और चीज़ के लिए)।
मैंने अपनी पिछली टिप्पणियों में से एक में जो कहा था, उसके विपरीत, DATETIME और TIMESTAMP फ़ील्ड करें अलग व्यवहार करें। TIMESTAMP फ़ील्ड (जैसा कि दस्तावेज़ इंगित करते हैं) जो कुछ भी आप उन्हें "YYYY-MM-DD hh:mm:ss" प्रारूप में भेजते हैं और इसे अपने वर्तमान समय क्षेत्र से UTC समय में परिवर्तित करते हैं। जब भी आप डेटा पुनर्प्राप्त करते हैं तो विपरीत पारदर्शी रूप से होता है। DATETIME फ़ील्ड यह रूपांतरण नहीं करते हैं। आप जो कुछ भी उन्हें भेजते हैं वे ले लेते हैं और सीधे उसे स्टोर कर लेते हैं।
न तो DATETIME और न ही TIMESTAMP फ़ील्ड प्रकार DST का पालन करने वाले समयक्षेत्र में डेटा को सटीक रूप से संग्रहीत कर सकते हैं . यदि आप "2009-11-01 01:30:00" स्टोर करते हैं, तो फ़ील्ड के पास यह भेद करने का कोई तरीका नहीं है कि आप 1:30 बजे का कौन सा संस्करण चाहते हैं - - -04:00 या -05:00 संस्करण।
ठीक है, इसलिए हमें अपने डेटा को एक गैर डीएसटी समय क्षेत्र (जैसे यूटीसी) में संग्रहित करना चाहिए। TIMESTAMP फ़ील्ड इस डेटा को सही तरीके से संभालने में असमर्थ हैं क्योंकि मैं समझाता हूँ:यदि आपका सिस्टम DST टाइमज़ोन पर सेट है तो आप TIMESTAMP में जो डालते हैं वह वह नहीं हो सकता है जो आप वापस प्राप्त करते हैं। यहां तक कि अगर आप इसे डेटा भेजते हैं जिसे आप पहले ही यूटीसी में परिवर्तित कर चुके हैं, तब भी यह डेटा को आपके स्थानीय समय क्षेत्र में मान लेगा और यूटीसी में एक और रूपांतरण करेगा। यह TIMESTAMP-प्रवर्तित लोकल-टू-यूटीसी-बैक-टू-लोकल राउंडट्रिप नुकसानदेह है जब आपका स्थानीय टाइमज़ोन डीएसटी देखता है ("2009-11-01 01:30:00" से 2 अलग-अलग संभावित समय के लिए मैप करता है)।
DATETIME के साथ आप अपने डेटा को किसी भी समय क्षेत्र में संग्रहीत कर सकते हैं और आश्वस्त रहें कि आप जो कुछ भी भेजेंगे वह आपको वापस मिल जाएगा (आपको हानिकारक राउंडट्रिप रूपांतरणों में मजबूर नहीं किया जाता है जो TIMESTAMP फ़ील्ड आप पर थोपते हैं)। तो समाधान यह है कि DATETIME फ़ील्ड का उपयोग करें और फ़ील्ड में सहेजने से पहले अपने सिस्टम समय क्षेत्र से उस गैर-डीएसटी क्षेत्र में कनवर्ट करें जिसमें आप इसे सहेजना चाहते हैं (मुझे लगता है कि यूटीसी शायद सबसे अच्छा विकल्प है)। यह आपको अपनी स्क्रिप्टिंग भाषा में रूपांतरण तर्क बनाने की अनुमति देता है ताकि आप "2009-11-01 01:30:00 -04:00" या "" 2009-11-01 01:30 के यूटीसी समकक्ष को स्पष्ट रूप से सहेज सकें:00 -05:00"।
ध्यान देने योग्य एक और महत्वपूर्ण बात यह है कि यदि आप अपनी तिथियों को DST TZ में संग्रहीत करते हैं, तो MySQL का दिनांक/समय गणित कार्य DST सीमाओं के आसपास ठीक से काम नहीं करता है। तो यूटीसी में बचत करने का और भी कारण।
संक्षेप में अब मैं यह करता हूं:
डेटाबेस से डेटा पुनर्प्राप्त करते समय:
सटीक यूनिक्स टाइमस्टैम्प प्राप्त करने के लिए डेटाबेस से डेटा को MySQL के बाहर यूटीसी के रूप में स्पष्ट रूप से व्याख्या करें। मैं इसके लिए PHP के स्ट्रेटोटाइम() फ़ंक्शन या इसकी डेटटाइम क्लास का उपयोग करता हूं। यह MySQL के CONVERT_TZ() या UNIX_TIMESTAMP() फ़ंक्शंस का उपयोग करके MySQL के अंदर मज़बूती से नहीं किया जा सकता है क्योंकि CONVERT_TZ केवल 'YYYY-MM-DD hh:mm:ss' मान को आउटपुट करेगा जो अस्पष्टता की समस्याओं से ग्रस्त है, और UNIX_TIMESTAMP() इसे मानता है इनपुट सिस्टम टाइमज़ोन में है, न कि उस टाइमज़ोन में, जिसमें डेटा वास्तव में (UTC) में स्टोर किया गया था।
डेटाबेस में डेटा संग्रहीत करते समय:
अपनी तिथि को उस सटीक UTC समय में बदलें जो आप MySQL के बाहर चाहते हैं। उदाहरण के लिए:PHP की डेटटाइम कक्षा के साथ आप "2009-11-01 1:30:00 ईएसटी" को "2009-11-01 1:30:00 ईडीटी" से अलग निर्दिष्ट कर सकते हैं, फिर इसे यूटीसी में परिवर्तित कर सकते हैं और सही यूटीसी समय बचा सकते हैं आपके DATETIME फ़ील्ड में.
ओफ़्फ़। सभी के इनपुट और मदद के लिए बहुत-बहुत धन्यवाद। उम्मीद है कि यह किसी और को सड़क के नीचे सिरदर्द से बचाता है।
BTW, मैं इसे MySQL 5.0.22 और 5.0.27 पर देख रहा हूँ
