2038 की समस्या, ठीक से समझाई गई

19 जनवरी 2038 को 03:14:07 UTC पर, 1 जनवरी 1970 से बीते सेकंडों की संख्या 2,147,483,647 तक पहुँच जाती है। यही सबसे बड़ा मान है जो एक सचिह्न 32-बिट पूर्णांक धारण कर सकता है। उसके एक सेकंड बाद वह −2,147,483,648 पर लिपट जाता है, जिसे वे तंत्र 13 दिसंबर 1901 पढ़ते हैं।

यह एक वास्तविक समस्या है जिसकी तारीख पक्की है, और यही बात इसे सॉफ़्टवेयर की समस्याओं में असामान्य बनाती है।

32 बिट ही क्यों

यूनिक्स समय की रचना 1970 के दशक के आरंभ में हुई, जब 32-बिट पूर्णांक स्वाभाविक शब्द-आकार था और अड़सठ वर्ष की गुंजाइश उदार लगती थी। उन तंत्रों में time_t प्रकार एक सचिह्न 32-बिट पूर्णांक था, और वह चुनाव सी भाषा में, सी को लपेटने वाली हर भाषा में, फ़ाइल स्वरूपों में, संजाल नियमावलियों में और डेटाबेस की संरचनाओं में फैल गया।

चिह्न ही अतिप्रवाह को उसका विशिष्ट लक्षण देता है। एक अचिह्न 32-बिट गणना 2106 तक चलती; सचिह्न गणना अपना परास 1970 के इर्द-गिर्द बाँटती है, इसलिए अतिप्रवाह शून्य के बजाय 1901 में उतरता है।

अब तक क्या हो चुका है

2038 की समस्या वर्षों से उत्पादन में विफलताएँ दे रही है, क्योंकि सॉफ़्टवेयर नियमित रूप से भविष्य की तिथियाँ गिनता है।

• तीस वर्षीय आवास-ऋण की गणनाएँ 2008 में उस सीमा को पार करने लगीं।
• प्रमाणपत्रों की समाप्ति तिथियाँ, संचिका के जीवनकाल और नियत कार्य बार-बार इससे टकराए हैं।
• 2006 में AOLserver की डिफ़ॉल्ट डेटाबेस समय-सीमा में एक दोष — जो एक अरब सेकंड पर नियत थी, और यह तब तक ठीक था जब तक ठीक रहा — तब सॉफ़्टवेयर को गिरा गया जब गणना की गई समाप्ति भर गई।

ढर्रा यह है कि विफलता तारीख से बहुत पहले आती है, उस कूट में जो सबसे दूर आगे देखता है।

क्या पहले ही ठीक हो चुका है

स्थिति उस घबराहट से कहीं बेहतर है जो प्रचारित होती है।

• 64-बिट तंत्र: लगभग हर 64-बिट मंच पर time_t 64 बिट का है। वह लगभग 292 अरब वर्षों में समाप्त होगा।
• 32 बिट पर लिनक्स: कर्नेल 5.6 (मार्च 2020) ने 32-बिट संरचनाओं पर 64-बिट time_t लाया, और बड़े वितरणों ने उसके अनुरूप उपयोक्ता-परिवेश जारी किया।
• जावास्क्रिप्ट: मिलीसेकंडों के लिए द्विशुद्धि दशमलव संख्या का उपयोग करता है, जो 1970 के दोनों ओर लगभग 275,000 वर्ष तक वैध है। इसे यह समस्या कभी रही ही नहीं।
• जावा: Instant 64-बिट सेकंड-गणना और नैनोसेकंड रखता है।
• पाइथन: उसके पूर्णांक स्वेच्छ शुद्धि के हैं; बंधन मंच की सी लाइब्रेरी है।
• PostgreSQL, MySQL 8.0.28+, SQL Server: 64-बिट समयांक भंडारण।

जोखिम कहाँ बचा है

अंतःस्थापित तंत्र। औद्योगिक नियंत्रक, चिकित्सा उपकरण, वाहन-इलेक्ट्रॉनिकी, मीटर और संवेदक — इनमें से बहुत बीस या तीस वर्ष की सेवा-आयु के लिए बने, बहुतों के पास अद्यतन का कोई रास्ता नहीं, और बहुत पहले ही लगाए जा चुके। असली जोखिम का बड़ा भाग यहीं है, और उसका कोई केंद्रीय लेखा नहीं।

8.0.28 से पहले MySQL का TIMESTAMP प्रकार। यह 32-बिट सेकंड-गणना है और इसका प्रलेखित अधिकतम 2038-01-19 03:14:07 है। DATETIME कभी प्रभावित नहीं हुआ। उत्पादन के आँकड़ों की बहुत बड़ी मात्रा उसी प्रभावित स्तंभ-प्रकार में बैठी है।

क्रमबद्ध आँकड़े और फ़ाइल स्वरूप। जिसने भी 32-बिट समय-क्षेत्र लिखा, वह 32-बिट समय-क्षेत्र ही रहता है, पढ़ने वाला चाहे कितना भी नया हो। पुराने अभिलेख स्वरूप, द्विआधारी नियमावलियाँ और डिस्क पर पड़ी संरचनाएँ उस बंधन को आगे ले जाती हैं।

अब भी सेवा में लगे 32-बिट निर्माण। कुछ अनुमार्गक, सेट-टॉप बॉक्स और लंबे जीवन वाले उपकरण बिना पैबंद वाली कर्नेल पर 32-बिट उपयोक्ता-परिवेश चलाते हैं।

इसका क्या करें

भंडारण-प्रकारों की जाँच करें। समयांक रखने वाले int(11) स्तंभ, पुराने संस्करणों पर MySQL का TIMESTAMP, और 32-बिट समय-क्षेत्र वाला कोई भी द्विआधारी स्वरूप खोजें। यहीं आँकड़े कूट से अधिक जीते हैं।

2038 के बाद की तिथियों से परीक्षण करें। एक परीक्षण-प्रबंध को 2040 पर नियत कीजिए और अपनी परीक्षण-शृंखला चलाइए। 2038 के अधिकांश दोष कोई कोशिश कर ले तो सहज ही दोहराए जा सकते हैं।

64-बिट पूर्णांक या ISO 8601 पंक्तियों को वरीयता दें। मिलीसेकंड रखने वाले BIGINT या TIMESTAMPTZ स्तंभ का ऐसा कोई क्षितिज नहीं जिस पर सोचना पड़े। ISO 8601 पंक्ति का तो बिलकुल नहीं, बस आकार और तुलना-गति की कीमत पर।

तिथियों को फिर कभी किसी 32-बिट वस्तु में मत रखिए। आधुनिक साज-सामान पर भंडारण की बचत निरर्थक है, और क्षितिज अब सामान्य सॉफ़्टवेयर की सेवा-आयु के भीतर आ चुका है।

अन्य तिथि-क्षितिज

2038 निकटतम है, अकेला नहीं।

• 2036: NTP का 32-बिट युग-क्षेत्र 7 फ़रवरी को पलटता है। NTPv4 इसे सँभालता है, पर संस्थापनाएँ भिन्न-भिन्न हैं।
• 2106: अचिह्न 32-बिट सेकंड-गणनाएँ लिपट जाती हैं।
• 2262: 64-बिट नैनोसेकंड गणनाएँ भर जाती हैं — यही Go भाषा का time.Time अपने नैनोसेकंड निरूपण में है, और pandas का डिफ़ॉल्ट datetime64[ns] भी।

आँकड़ा-संसाधन का कूट लिखने वाले किसी भी व्यक्ति के लिए यह अंतिम क्षितिज सुनने में जितना दूर लगता है उससे निकट है, और यह वही भूल है दूसरे पैमाने पर: उपयोगी होने भर को महीन इकाई, ऐसी चौड़ाई में जो उस समय उदार जान पड़ी।

अपने तंत्रों की जाँच कैसे करें

चार जाँचें, बढ़ते श्रम के क्रम में।

अपने डेटाबेस के स्तंभ-प्रकार देखिए। PostgreSQL में SELECT column_name, data_type FROM information_schema.columns WHERE data_type LIKE '%timestamp%' बता देता है कि आपके पास क्या है; timestamp with time zone 64-बिट है और सुरक्षित। MySQL में 8.0.28 से पहले के परिसेवकों पर TIMESTAMP स्तंभ खोजिए — वही जोखिम में हैं, और DATETIME कभी नहीं था।

घड़ी आगे बढ़ाइए। एक फेंक देने योग्य कंटेनर में तंत्र की तिथि 2040 पर कीजिए और परीक्षण-शृंखला चलाइए। तरीका कच्चा है और हैरान करने वाली मात्रा में दोष पकड़ता है, क्योंकि सीमा पार होने के बाद 2038 का कोई दोष सूक्ष्म नहीं रहता।

32-बिट समय-प्रकार खोजिए। सी और सी++ में, 32-बिट लक्ष्य पर समय का मान रखने वाला हर स्पष्ट int या long। क्रमांकन की संरचनाओं में, हर चार-बाइट समय-क्षेत्र। अनुप्रयोग-कूट में, हर वह जगह जहाँ भंडारण या प्रेषण के लिए समयांक को 32-बिट पूर्णांक में ढाला जाता है।

परीक्षण-प्रबंधों में केवल निकट नहीं, दूर के भविष्य की भी जाँच कीजिए। «अभी से एक दिन आगे» वाला परीक्षण 2038 तक पास होता रहेगा और फिर किसी मंगलवार गिर जाएगा। 2040 की स्पष्ट तिथि वाला परीक्षण आज ही गिरता है, जब उसे सुधारने वाला कोई उपलब्ध है।

क्या न करें

इसे अचिह्न 32-बिट पूर्णांकों पर जाकर मत «सुलझाइए»। यह अड़सठ वर्ष खरीदता है, 1970 से पहले की कोई भी तिथि दर्शाने की क्षमता छीन लेता है, और वही बातचीत उस पर डाल देता है जो 2106 में इस तंत्र को सँभालेगा। चार और आठ बाइट का अंतर दूसरे प्रवासन के लायक नहीं।

यह मत मानिए कि कोई आधुनिक भाषा आपको बचा लेगी। अनुप्रयोग-कूट पूरी तरह सुरक्षित हो सकता है जबकि जो आँकड़े वह पढ़ता है उन्हें किसी असुरक्षित चीज़ ने लिखा हो — फ़ाइल स्वरूप और संचार नियमावलियाँ उस बंधन को हर पुनर्लेखन के आर-पार ले जाती हैं।