मैंने इसे एक समुदाय विकी के रूप में चिह्नित किया है इसलिए अपने खाली समय में संपादित करने के लिए स्वतंत्र महसूस करें।
वर्ष 2038 की समस्या वास्तव में क्या है?
"वर्ष 2038 की समस्या (जिसे यूनिक्स मिलेनियम बग, Y2K38 के रूप में भी जाना जाता है, Y2K समस्या के सादृश्य द्वारा) कुछ कंप्यूटर सॉफ़्टवेयर को वर्ष 2038 से पहले या वर्ष में विफल कर सकता है। समस्या उन सभी सॉफ़्टवेयर और सिस्टम को प्रभावित करती है जो सिस्टम समय को एक हस्ताक्षरित 32 के रूप में संग्रहीत करते हैं। -बिट पूर्णांक, और 1 जनवरी, 1970 को 00:00:00 UTC के बाद से इस संख्या की व्याख्या सेकंड की संख्या के रूप में करें।"
ऐसा क्यों होता है और होने पर क्या होता है?
मंगलवार, 19 जनवरी 2038 को 03:14:07 UTC से आगे का समय 'चारों ओर लपेटा जाएगा' और आंतरिक रूप से एक ऋणात्मक संख्या के रूप में संग्रहीत किया जाएगा, जिसे ये सिस्टम 2038 के बजाय 13 दिसंबर, 1901 में एक समय के रूप में व्याख्यायित करेंगे। यह इस तथ्य के कारण है कि UNIX युग (1 जनवरी) के बाद से सेकंड की संख्या 1970 00:00:00 GMT) 32-बिट हस्ताक्षरित पूर्णांक के लिए कंप्यूटर के अधिकतम मान को पार कर गया होगा।
हम इसे कैसे हल करते हैं?
- लंबे डेटा प्रकारों का उपयोग करें (64 बिट पर्याप्त हैं)
- MySQL (या MariaDB) के लिए, यदि आपको समय की जानकारी की आवश्यकता नहीं है तो
DATEका उपयोग करने पर विचार करें स्तंभ प्रकार। यदि आपको अधिक सटीकता की आवश्यकता है, तोDATETIMEका उपयोग करें इसके बजायTIMESTAMP. सावधान रहें किDATETIMEकॉलम समय क्षेत्र के बारे में जानकारी संग्रहीत नहीं करते हैं, इसलिए आपके आवेदन को यह जानना होगा कि किस समय क्षेत्र का उपयोग किया गया था। - विकिपीडिया पर वर्णित अन्य संभावित समाधान
- MySQL डेवलपर द्वारा इस बग को ठीक करने की प्रतीक्षा करें एक दशक से भी पहले की सूचना दी।
क्या इसका उपयोग करने के लिए कोई संभावित विकल्प हैं, जो समान समस्या उत्पन्न नहीं करते हैं?
डेटाबेस में दिनांक संग्रहीत करने के लिए जहाँ भी संभव हो बड़े प्रकारों का उपयोग करने का प्रयास करें:64-बिट पर्याप्त है - GNU C और POSIX/SuS में एक लंबा लंबा प्रकार, या sprintf('%u'...) PHP या BCmath एक्सटेंशन में।
कुछ संभावित उपयोग के मामले क्या हैं, भले ही हम अभी 2038 में नहीं हैं?
तो एक MySQL DATETIME इसकी रेंज 1000-9999 है, लेकिन TIMESTAMP की रेंज केवल 1970-2038 है। यदि आपका सिस्टम जन्मतिथि, भविष्य की आगे की तारीखें (जैसे 30 साल के बंधक), या इसी तरह के स्टोर करता है, तो आप पहले से ही इस बग में भाग लेने जा रहे हैं। फिर से, TIMESTAMP का उपयोग न करें यदि यह एक समस्या होने वाली है।
टाइमस्टैम्प का उपयोग करने वाले मौजूदा एप्लिकेशन का हम क्या कर सकते हैं, तथाकथित समस्या से बचने के लिए, जब यह वास्तव में होती है?
कुछ PHP अनुप्रयोग अभी भी 2038 के आसपास होंगे, हालांकि यह अनुमान लगाना कठिन है कि वेब शायद ही अभी तक एक विरासती मंच है।
TIMESTAMP में कनवर्ट करने के लिए डेटाबेस तालिका कॉलम को बदलने की प्रक्रिया यहां दी गई है से DATETIME . तक . यह एक अस्थायी कॉलम बनाने से शुरू होता है:
# rename the old TIMESTAMP field
ALTER TABLE `myTable` CHANGE `myTimestamp` `temp_myTimestamp` int(11) NOT NULL;
# create a new DATETIME column of the same name as your old column
ALTER TABLE `myTable` ADD `myTimestamp` DATETIME NOT NULL;
# update all rows by populating your new DATETIME field
UPDATE `myTable` SET `myTimestamp` = FROM_UNIXTIME(temp_myTimestamp);
# remove the temporary column
ALTER TABLE `myTable` DROP `temp_myTimestamp`
संसाधन
