क्या 19 जनवरी 2038 3:14:08 पर लिनक्स घड़ी विफल हो जाएगी?

Question

मैं इस बारे में थोड़ा चिंतित हूं। इसे "वर्ष 2038 समस्या" कहा जाता है। क्या लिनक्स कर्नेल या उबंटू इसके बाद की तारीखों को संभालने के लिए तैयार है, जैसे कि 12.04?

Comments

क्या आपने 19 जनवरी, 2038 3:14:07 की तरह अपनी घड़ी सेट करने की कोशिश की है और एक सेकंड रुकें?

— gertvdijk

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

— verpfeilt

बग पहले से तय था।

— thePiercingPrince

सिस्टम क्लॉक (वैसे भी हाल की कर्नेल पर नहीं); कुछ डेटा संरचनाएं (और इसका उपयोग करने वाले प्रोग्राम) अनौपचारिक व्यवहार प्रदर्शित कर सकती हैं। मेरी राय में, यह एम्बेडेड उपकरणों के साथ एक समस्या होगी - उन पर वर्तमान कोड चलने की संभावना बहुत कम है।

— पिस्कवेर

@hmayag: मैं "टोस्टर," अधिक "ट्रैफिक लाइट कंट्रोलर" नहीं सोच रहा था। उन चीजों को उपभोक्ता-श्रेणी के इलेक्ट्रॉनिक्स की तुलना में थोड़ा अधिक ऊबड़-खाबड़ है, और आसानी से उस जीवन काल ( आंशिक प्रतिस्थापन के साथ , लेकिन संभवतः उन्नयन के बिना) से अधिक हो सकता है - IIRC, Y2K के ठीक बाद ऐसे 1980 के दशक के इलेक्ट्रॉनिक्स के साथ कुछ मुद्दे थे।

— पिस्कवर

Answer 1

नहीं, यह विफल नहीं होगा। सबसे खराब स्थिति में, एक प्रोग्रामर के दृष्टिकोण से यह उम्मीद के मुताबिक काम करेगा: इसे 1901-12-13 दिनांक 20:01:52 तक रीसेट किया जाएगा:

ऐसा होने पर आप अपने वर्तमान वितरण को अपडेट नहीं करेंगे। " अपडेट करना आसान है। इनमें से एक अपडेट में निश्चित रूप से एक फिक्स होगा। " जैसे चोकोबाई ने कहा।

मुझे याद है कि यह 2000 से पहले 16-बिट मशीनों के साथ एक ही समस्या / प्रश्न था और अंत में यह कोई समस्या नहीं थी।

विकिपीडिया से एक समाधान:

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) तक सीमित करता है। हालांकि यह प्रोग्राम निष्पादित करने के लिए समस्या को हल करता है, यह बाइनरी डेटा फ़ाइलों के भीतर दिनांक मानों को संग्रहीत करने की समस्या को हल नहीं करता है, जिनमें से कई कठोर भंडारण प्रारूपों को नियोजित करते हैं। यह संगतता परतों के तहत चल रहे 32-बिट कार्यक्रमों के लिए समस्या को हल नहीं करता है और उन प्रोग्रामों के लिए समस्या को हल नहीं कर सकता है जो गलत तरीके से समय मूल्यों को अन्य प्रकार के चर में संग्रहीत करते हैं time_t।

मैं 64 बिट पर Ubuntu 13.04 का उपयोग करता हूं और, जिज्ञासा से, मैंने मैन्युअल रूप से 2038-01-19 03:13:00 तक समय बदल दिया। 03:14:08 के बाद कुछ नहीं हुआ था:

इसलिए इस समस्या से चिंतित होने की कोई बात नहीं है।

के बारे में अधिक:

• वर्ष 2038 समस्या - विकिपीडिया ।
• समय का अंत (यूनिक्स) - नंबरफाइल ।

Comments

यदि यह रीसेट करता है, तो यह विफल हो जाता है क्योंकि "विफल" से मेरा मतलब है "गलत तरीके से काम करना या काम नहीं करना"।

— thePiercingPrince

@LinuxDistance यह आपके दृष्टिकोण से होता है। लेकिन एक प्रोग्रामर के दृष्टिकोण से यह उम्मीद के मुताबिक काम करेगा: यह रीसेट हो जाएगा । यह माया कैलेंडर के अंत के साथ भी ऐसा ही था: दुनिया इस वजह से विफल नहीं हुई।

— रादु राईडेनू

मैं असहमत हूं? एक प्रोग्रामर के दृष्टिकोण से एक घड़ी को रीसेट नहीं करना चाहिए, इसलिए यह विफल हो जाएगा

— नैनी

टिप्पणियों में यह चर्चा व्यर्थ है। सवाल है "क्या लिनक्स कर्नेल या उबंटू इसके बाद की तारीखों को संभालने के लिए तैयार है?"। खैर, यह ऐसी तारीखों को संभालने में सक्षम नहीं है, इसलिए यह इस प्रश्न के संदर्भ में विफल है।

— gertvdijk

@gertvdijk "क्या" वर्तमान / वास्तविक "लिनक्स कर्नेल या उबंटू इसके बाद की तारीखों को संभालने के लिए तैयार है?"

— रादु राईडेनु

Answer 2

आप जाँच सकते हैं कि आपके कंप्यूटर का समय निम्नलिखित पर्ल स्क्रिप्ट का उपयोग करके दुर्घटनाग्रस्त होगा या नहीं:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

यदि आपका कंप्यूटर ठीक होगा, तो आपको यह मिलेगा:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

यदि आपका कंप्यूटर मेरा जैसा है, तो यह इस तरह से घूमेगा:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

यह भी कर सकता है:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

Comments

मुझे लगता है कि आप यहां पर्ल का परीक्षण कर रहे हैं, न कि कोर में वास्तविक ऑपरेटिंग सिस्टम। या आप, के उपयोग के साथ हैं ctime?

— gertvdijk

@gertvdijk खैर, यह पैच कंप्यूटर पर पहला आउटपुट देता है, और मेरा उबंटू लैपटॉप दूसरा देता है, जबकि तीसरा मेरे डेबियन सर्वर से है। मैंने वास्तव में कोड नहीं लिखा था, यह इंटरनेट पर उसी सटीक रूप में है।

— SkylarMT

की पुष्टि की। यदि आपके पास 64 बिट मशीन है, तो यह ठीक रहेगा। इसके अलावा ... हम में से किसके पास 32 बिट केवल मशीनें अभी भी वर्ष 2038 में चलेंगी?

— jrg

मैं एक सहकर्मी को 2038 समस्या का वर्णन करने के लिए इसकी तलाश में गया था, और उपरोक्त टिप्पणी करने के 2 साल बाद, मुझे बहुत कम संदेह है कि 2038 में हमारे पास 32 बिट मशीनें होंगी जो असफल हो जाएंगी। आह, युवा आशावाद।

— 13

@ जेम्स, शायद कुछ अनजाने में। आईओटी उपकरणों में संभवतः 32 बिट लिनक्स एम्बेडेड होगा। दुनिया का अंत? नहीं। कुछ जगहों पर कुछ परेशानी? निश्चित रूप से।

— प्रो।

Answer 3

मैंने 1996 में इस पीठ पर एक लघु पत्र लिखा और प्रकाशित किया। इसमें इसे प्रदर्शित करने के लिए एक लघु C कार्यक्रम शामिल था। मैंने एनटी- नेटवर्क टाइम प्रोटोकॉल के साथ इसी तरह के मुद्दों के बारे में डेविड मिल्स के साथ ईमेल किया था। मेरे उबंटू 14.04 64-बिट लैपटॉप पर पर्ल कोड ने सीमा प्रदर्शित नहीं की है, इसलिए अंतर्निहित 64-बिट लिबास को संशोधित किया जाना चाहिए।

हालांकि, मेरे लंबे-समय के परीक्षण कोड को चलाने से यूनिक्स ईपॉच के समय को दर्शाता है। तो सभी अतीत से 32-बिट कोड के साथ अच्छी तरह से नहीं है।

मेरा 1996 का पेपर, यूनिक्स का समय 2038 में समाप्त हो जाएगा! 2000 के बाद से मेरी वेबसाइट पर है। "UNIX टाइम" शीर्षक का एक संस्करण 1998 में "वर्ष 2000 में Y2K मिलेनियम कम्प्यूटिंग के लिए सर्वश्रेष्ठ अभ्यास" आईएसबीएन 0136465064 में प्रकाशित किया गया था।

Answer 4

64-बिट लिनक्स तैयार है, कम से कम अगर आप कोर ओएस इंटरफेस के बारे में बात कर रहे हैं (व्यक्तिगत अनुप्रयोग अभी भी इसे खराब कर सकते हैं)। time_t को पारंपरिक रूप से "लंबे" के लिए एक उपनाम के रूप में परिभाषित किया गया है और 64-बिट लिनक्स पर "लंबा" 64-बिट है।

32-बिट लिनक्स (और 64-बिट लिनक्स पर 32-बिट बायनेरिज़ के लिए संगतता परत) के लिए स्थिति बहुत कम रसीली है। सभी मौजूदा बायनेरिज़ को तोड़े बिना इसे तोड़ना और ठीक करना आसान काम नहीं है। एपीआई का एक पूरा गुच्छा समय_ का उपयोग करता है और कई मामलों में इसे डेटा संरचनाओं के हिस्से के रूप में एम्बेडेड किया जाता है, इसलिए न केवल एपीआई को उन डेटा संरचनाओं को दोहराया जाना चाहिए जिनके साथ वे काम करते हैं।

यहां तक ​​कि अगर बैकवर्ड संगतता के कुछ स्तर हैं, तो सभी बायनेरी जो सही समय प्राप्त करना चाहते हैं, उन्हें नए 64-बिट समय इंटरफेस का उपयोग करने के लिए पुनर्निर्माण करना होगा।

कुछ काम किया गया है (उदाहरण के लिए देखें https://lwn.net/Articles/643234/ और http://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html ), लेकिन हमें बताएं अभी भी एक पूर्ण समाधान से एक लंबा रास्ता तय करना है। यह स्पष्ट नहीं है कि क्या कभी भी सामान्य उद्देश्य 32-बिट वितरण होगा जो Y2K38 सुरक्षित हैं।