वर्ष 2038 समस्या |year 2038 problem
वर्ष 2038 की समस्या कई डिजिटल प्रणालियों में समय का प्रतिनिधित्व करने से संबंधित है क्योंकि 1 जनवरी 1970 से पारित सेकंड की संख्या और इसे हस्ताक्षरित 32-बिट बाइनरी पूर्णांक के रूप में संग्रहीत किया गया है। इस तरह के कार्यान्वयन 1914 2038 को 03:14:07 UTC के बाद बार-बार सांकेतिक शब्दों में बदलना नहीं कर सकते। Y2K समस्या की तरह, वर्ष 2038 की समस्या चुनी हुई भंडारण इकाई की अपर्याप्त क्षमता के कारण होती है।
तकनीकी कारण
नवीनतम समय जिसे यूनिक्स के हस्ताक्षरित 32-बिट पूर्णांक समय प्रारूप में दर्शाया जा सकता है, मंगलवार 19 जनवरी 2038 (231-1 = 2,147,483,647 सेकंड 1 जनवरी 1970) के बाद UTC है। [1] इसके अलावा टाइम्स चारों ओर से लपेट जाएगा और आंतरिक रूप से एक नकारात्मक संख्या के रूप में संग्रहीत किया जाएगा, जिसे ये सिस्टम 19 जनवरी 2038 के बजाय 13 दिसंबर 1901 को हुआ होगा। यह पूर्णांक अतिप्रवाह के कारण होता है। काउंटर प्रयोग करने योग्य अंक बिट्स से बाहर निकलता है, इसके बजाय साइन बिट को फ़्लिप करता है, और एक अधिकतम नकारात्मक संख्या (सकारात्मक अनंत की ओर, गिनती जारी रखने) की रिपोर्ट करता है। ऐसी प्रणालियों पर गलत गणना के परिणामस्वरूप उपयोगकर्ताओं और अन्य भरोसा करने वाले दलों के लिए समस्या पैदा हो सकती है।
भविष्य की तारीखों के साथ काम करने वाले कार्यक्रम जल्द ही समस्याओं में चलना शुरू कर देंगे; उदाहरण के लिए, एक कार्यक्रम जो भविष्य में 20 साल की तारीखों के साथ काम करता है, उसे 19 जनवरी 2018 से बाद में तय नहीं किया जाना चाहिए था।
प्रारंभिक समस्याएं
मई 2006 में, AOLserver सॉफ्टवेयर में Y2038 समस्या के शुरुआती प्रकटीकरण की रिपोर्ट सामने आई। सॉफ़्टवेयर को एक डेटाबेस अनुरोध को संभालने के लिए एक कीचड़ के साथ डिज़ाइन किया गया था जो कि "कभी नहीं" बाहर होना चाहिए। विशेष रूप से इस विशेष मामले को संभालने के बजाय, प्रारंभिक डिजाइन ने भविष्य में केवल एक मनमाना समय-आउट तिथि निर्दिष्ट की। सर्वर के लिए डिफ़ॉल्ट कॉन्फ़िगरेशन ने निर्दिष्ट किया कि अनुरोध को एक अरब सेकंड के बाद समाप्त होना चाहिए। 13 मई 2006 को 01:27:28 UTC के बाद एक बिलियन सेकंड (लगभग 32 वर्ष) 2038 कटऑफ की तारीख से परे है। इस प्रकार, इस समय के बाद, टाइम-आउट गणना बह निकली और एक तारीख वापस कर दी जो वास्तव में अतीत में थी, जिससे सॉफ्टवेयर क्रैश हो गया। जब समस्या का पता चला, तो AOLServer ऑपरेटरों को कॉन्फ़िगरेशन फ़ाइल को संपादित करना था और टाइम-आउट को कम मूल्य पर सेट करना था। [२] [३]
प्रतीक्षा अवधि [4] लगाने के लिए प्रोग्राम किए गए गेम या एप्लिकेशन के खिलाड़ी इस समस्या में चल रहे हैं, जब वे उन उपकरणों पर प्रतीक्षा अवधि के आसपास काम करने का प्रयास करते हैं जो कोडिंग को परेशान करते हैं, अपने उपकरणों को मैन्युअल रूप से 19 जनवरी 2038 से पहले की तारीख तक सेट करते हैं, लेकिन ऐसा करने में असमर्थ हैं, क्योंकि 32-बिट यूनिक्स समय प्रारूप का उपयोग किया जा रहा है।
कमजोर सिस्टम
एंबेडेड सिस्टम जो गणना या नैदानिक लॉगिंग के लिए तारीखों का उपयोग करते हैं, 2038 बग से प्रभावित होने की सबसे अधिक संभावना है। [५]
उड़ान से लेकर ऑटोमोबाइल तक कई परिवहन प्रणालियाँ एम्बेडेड सिस्टम का बड़े पैमाने पर उपयोग करती हैं। ऑटोमोटिव सिस्टम में, इसमें एंटी-लॉक ब्रेकिंग सिस्टम (ABS), इलेक्ट्रॉनिक स्टेबिलिटी कंट्रोल (ESC / ESP), ट्रैक्शन कंट्रोल (TCS) और ऑटोमैटिक फोर-व्हील ड्राइव शामिल हो सकते हैं; विमान जड़त्वीय मार्गदर्शन प्रणाली और जीपीएस रिसीवर का उपयोग कर सकते हैं। हालांकि, इसका मतलब यह नहीं है कि ये सभी सिस्टम बग से पीड़ित होंगे, क्योंकि कई ऐसे सिस्टम को तारीखों तक पहुंच की आवश्यकता नहीं होती है। ऐसा करने वालों के लिए, वे प्रणालियां जो केवल गणना की प्रकृति से, समय / तिथियों और न कि निरपेक्ष समय / तिथियों के बीच के अंतर को ट्रैक करती हैं, एक समस्या का अनुभव नहीं करती हैं। यह CARB (कैलिफोर्निया एयर रिसोर्स बोर्ड) जैसे विधायी मानकों के आधार पर ऑटोमोटिव डायग्नोस्टिक्स के लिए मामला है। [६]
एम्बेडेड सिस्टम का एक और प्रमुख उपयोग संचार उपकरणों में है, जिसमें सेल फोन और इंटरनेट उपकरण (राउटर, वायरलेस एक्सेस पॉइंट्स, आदि) शामिल हैं, जो एक सटीक समय और तारीख को स्टोर करने पर निर्भर करते हैं और तेजी से यूनिक्स जैसे ऑपरेटिंग सिस्टम पर आधारित होते हैं। उदाहरण के लिए, बग 32-बिट एंड्रॉइड क्रैश पर चलने वाले कुछ उपकरणों को बनाता है और समय के साथ उस तारीख में बदलने पर पुनरारंभ नहीं होता है। [7]
कंप्यूटर सिस्टम प्रौद्योगिकी में आधुनिक 18-24 महीने के पीढ़ीगत अद्यतन के बावजूद, एम्बेडेड सिस्टम को मशीन के जीवनकाल को अंतिम रूप देने के लिए डिज़ाइन किया गया है जिसमें वे एक घटक हैं। यह अनुमान लगाया जा सकता है कि इनमें से कुछ प्रणालियां अभी भी 2038 में उपयोग में आ सकती हैं। यह अव्यवहारिक हो सकता है या, कुछ मामलों में, इन सिस्टमों को चलाने वाले सॉफ़्टवेयर को अपग्रेड करना असंभव है, अंततः 32-बिट time_t सीमाओं को ठीक करने के लिए प्रतिस्थापन की आवश्यकता होती है।
MySQL डेटाबेस के अंतर्निहित कार्य जैसे UNIX_TIMESTAMP () 19 जनवरी 2038 को 03:14:07 UTC के बाद 0 वापस आएगा। [38]
समय की समस्याओं के साथ डेटा संरचनाएं
आज उपयोग में आने वाली कई डेटा संरचनाओं में 32-बिट समय प्रतिनिधित्व उनकी संरचना में अंतर्निहित है। इन डेटा संरचनाओं की एक पूरी सूची को प्राप्त करना लगभग असंभव है, लेकिन अच्छी तरह से ज्ञात डेटा संरचनाएं हैं जिनके पास यूनिक्स समय समस्या है:
फ़ाइल सिस्टम (कई फाइल सिस्टम केवल 32 बिट्स का उपयोग करते हैं जो इनोड्स के समय का प्रतिनिधित्व करते हैं)
बाइनरी फ़ाइल प्रारूप (जो 32-बिट समय फ़ील्ड का उपयोग करते हैं)
डेटाबेस (जिसमें 32-बिट समय फ़ील्ड हैं)
SQL जैसे UNIX_TIMESTAMP () कमांड की तरह डेटाबेस क्वेरी लैंग्वेज
डेटा संरचनाओं का उपयोग करने वाले सिस्टम के उदाहरणों में 32-बिट समय प्रतिनिधित्व शामिल हो सकते हैं:
एम्बेडेड कारखाना, रिफाइनरी नियंत्रण और निगरानी उपतंत्र
मिश्रित चिकित्सा उपकरण
मिश्रित सैन्य उपकरण
32-बिट समय अभ्यावेदन वाले डेटा संरचनाओं का उपयोग करने वाली कोई भी प्रणाली जोखिम पेश करेगी। जोखिम की डिग्री विफलता के मोड पर निर्भर है।
नेटवर्क टाइम प्रोटोकॉल टाइमस्टैम्प
नेटवर्क टाइम प्रोटोकॉल (NTP) से संबंधित अतिप्रवाह समस्या है, जो 2038 के बजाय 2036 में ही प्रकट होती है। NTP द्वारा उपयोग किए जाने वाले 64-बिट टाइमस्टैम्प में सेकंड के लिए 32-बिट भाग और आंशिक-सेकंड के लिए 32-बिट भाग होता है, NTP को हर 232 सेकंड (136 वर्ष) और 2−32 सेकंड (233 पिकोसेकंड) का एक सैद्धांतिक रिज़ॉल्यूशन रोल करने वाला एक समय का पैमाना। NTP 1 जनवरी 1900 की अवधि का उपयोग करता है। पहला रोलओवर 2036 में होता है, UNIX वर्ष 2038 समस्या से पहले।
कार्यान्वयन को अन्य स्रोतों से अनुमानित समय के ज्ञान का उपयोग करके एनटीपी समय की अवहेलना करनी चाहिए। चूंकि एनटी केवल टाइमस्टैम्प और उनके पूर्ण मूल्यों के बीच के अंतर के साथ काम करता है, इसलिए रैपराउंड गणना में अदृश्य है जब तक कि टाइमस्टैम्प एक दूसरे के 68 साल के भीतर होते हैं। हालांकि, एक रैपराउंड के बाद भी ग्राहकों को दो समस्याओं का सामना करना पड़ सकता है:
संभव समाधान
वर्ष 2038 समस्या के लिए कोई सार्वभौमिक समाधान नहीं है। Time_t डेटा प्रकार की परिभाषा में कोई भी परिवर्तन कोड संगतता समस्याओं के परिणामस्वरूप किसी भी अनुप्रयोग में होगा जिसमें दिनांक और समय प्रतिनिधित्व हस्ताक्षरित 32-बिट time_t पूर्णांक की प्रकृति पर निर्भर होते हैं। उदाहरण के लिए, बदलकर time_t को एक अहस्ताक्षरित 32-बिट पूर्णांक में, जो वर्ष 2106 तक सीमा को बढ़ाएगा, 1970 से पहले की तारीखों को स्टोर, पुनः प्राप्त या हेरफेर करने वाले कार्यक्रमों को प्रतिकूल रूप से प्रभावित करेगा, क्योंकि ऐसी तिथियां नकारात्मक संख्याओं द्वारा दर्शायी जाती हैं। मौजूदा सिस्टम में time_t प्रकार का आकार 64-बिट तक बढ़ने से संरचनाओं के लेआउट और कार्यों के बाइनरी इंटरफ़ेस में असंगत परिवर्तन हो सकते हैं।
डीवीबी और एटीएससी के साथ समस्या के लिए कोई सार्वभौमिक समाधान भी नहीं है, विरासत प्राप्तकर्ताओं के साथ मुद्दों के कारण वास्तविक समय में प्रेषित तारीखें। इस मुद्दे को या तो संगठन द्वारा स्वीकार या हल किया जाना बाकी है। प्रभावित तारीखों के बाद प्रोग्रामिंग गाइड और स्वचालित तिथि सिंक्रनाइज़ेशन जैसी सभी समय-संबंधित मेटाडेटा सेवाओं को बंद करने के लिए एकमात्र समाधान होगा। एक संभावित विकल्प विनिर्देशों के प्रभावित हिस्से के लिए नए टेबल प्रकार बनाने और तय पूर्णांक के बजाय आईएसओ 8601 तिथि तार का उपयोग करना होगा - जैसा कि आईएसओ 9660 और आईएसओ 13346 फाइलसिस्टम में उपयोग किया जाता है।
64-बिट हार्डवेयर पर चलने के लिए डिज़ाइन किए गए अधिकांश ऑपरेटिंग सिस्टम पहले से ही हस्ताक्षरित 64-बिट time_t पूर्णांक का उपयोग करते हैं। एक हस्ताक्षरित 64-बिट मूल्य का उपयोग करना एक नई रैपराउंड तारीख का परिचय देता है जो ब्रह्मांड की अनुमानित आयु से बीस गुना अधिक है: अब से लगभग 292 बिलियन वर्ष, रविवार को 15:30:08 यूटीसी पर, 4 दिसंबर 292,277,026,596। तिथियों पर गणना करने की क्षमता इस तथ्य से सीमित है कि tm_year वर्ष के लिए 1900 पर शुरू होने वाले हस्ताक्षरित 32 बिट पूर्णांक मान का उपयोग करता है। यह वर्ष को अधिकतम 2,147,485,547 (2,147,483,647 + 1900) तक सीमित करता है। 10]
FreeBSD 32-बिट i386 [11] को छोड़कर सभी 32-बिट और 64-बिट आर्किटेक्चर के लिए 64-बिट time_t का उपयोग करता है।
NetBSD संस्करण 6.0 (अक्टूबर 2012 में जारी) के साथ शुरू, NetBSD ऑपरेटिंग सिस्टम 32-बिट और 64-बिट आर्किटेक्चर दोनों के लिए 64-बिट time_t का उपयोग करता है। 32-बिट time_t के साथ पुराने NetBSD रिलीज़ के लिए संकलित किए गए अनुप्रयोगों को एक द्विआधारी संगतता परत के माध्यम से समर्थन किया जाता है, लेकिन ऐसे पुराने अनुप्रयोग अभी भी वर्ष 2038 की समस्या से ग्रस्त होंगे। [12]
मई 2014 में जारी संस्करण 5.5 के बाद से ओपनबीएसडी, 32-बिट और 64-बिट आर्किटेक्चर दोनों के लिए 64-बिट टाइम_ टी का उपयोग करता है। NetBSD के विपरीत, कोई बाइनरी संगतता परत नहीं है। इसलिए, 32-बिट time_t की अपेक्षा रखने वाले एप्लिकेशन और time_t से अलग समय मानों को संग्रहीत करने वाले कुछ अनुप्रयोगों का उपयोग हो सकता है। [13]
लिनक्स 64-बिट आर्किटेक्चर के लिए केवल 64-बिट time_t का उपयोग करता है; शुद्ध 32-बिट ABI को पिछड़ी संगतता के कारण नहीं बदला गया है। [१४] 32-बिट आर्किटेक्चर पर 64-बिट time_t का समर्थन करने के लिए, ज्यादातर एम्बेडेड लिनक्स सिस्टम के लिए काम चल रहा है, [15] [16]।
लिनक्स के लिए x32 ABI (जो 32-बिट पतों वाले प्रोग्राम के लिए एक वातावरण को परिभाषित करता है लेकिन प्रोसेसर को 64-बिट मोड में चलाने के लिए) 64-बिट time_t का उपयोग करता है। चूंकि यह एक नया वातावरण था, इसलिए विशेष अनुकूलता सावधानियों की आवश्यकता नहीं थी। [१४]
नेटवर्क फ़ाइल सिस्टम संस्करण 4 ने अपने समय क्षेत्र को nfstime4 {int64_t सेकंड के रूप में परिभाषित किया है; दिसंबर 2000 से uint32_t सेकंड;} [17] सेकंड फ़ील्ड के लिए शून्य से अधिक मान 0-घंटे, 1 जनवरी, 1970 के बाद की तारीखों को सूचित करते हैं। सेकंड फ़ील्ड के लिए शून्य से कम मान 0-घंटे, 1 जनवरी, 1970 से पहले की तारीख़ों को निरूपित करते हैं। दोनों ही मामलों में, nseconds (nanoseconds ) अंतिम समय के प्रतिनिधित्व के लिए फ़ील्ड को सेकंड फ़ील्ड में जोड़ा जाना है।
वैकल्पिक प्रस्ताव बनाए गए हैं (जिनमें से कुछ उपयोग में हैं), जैसे कि हस्ताक्षर किए गए 64-बिट पूर्णांक में एक युगांतर (आमतौर पर या तो 1 जनवरी 1970 या 1 जनवरी 2000) के बाद से मिलीसेकंड या माइक्रोसेकंड स्टोर करना, न्यूनतम 300,000 वर्ष प्रदान करना। माइक्रोसेकंड संकल्प पर। [18] [१ ९] नए समय के अभ्यावेदन के अन्य प्रस्ताव विभिन्न पूर्वाभास, सीमाएँ और आकार प्रदान करते हैं (लगभग हमेशा 32 बिट्स से अधिक व्यापक), साथ ही अन्य संबंधित समस्याओं को हल करते हैं, जैसे कि लीप सेकंड की हैंडलिंग। विशेष रूप से, TAI64 [20] टेम्प्स एटॉमिक अंतर्राष्ट्रीय मानक का एक कार्यान्वयन है, एक दूसरे को परिभाषित करने और संदर्भ के फ्रेम के लिए वर्तमान अंतर्राष्ट्रीय वास्तविक समय मानक।
tag - year 2038 problem
No comments:
Post a Comment