वर्ष 2038 की समस्या: Unix समय, 32-बिट ओवरफ़्लो और Y2K38

19 जनवरी 2038 को क्या होता है

03:14:07 UTC पर signed 32-बिट सेकंड का मान 2147483647 है। एक जोड़ने के लिए उस प्रकार की धनात्मक सीमा के बाहर का मान चाहिए।

Signed 32-बिट Unix समय ओवरफ़्लो क्यों होता है

एक बिट चिह्न दर्शाता है, इसलिए अधिकतम धनात्मक पूर्णांक 2^31 - 1 रहता है। उस सीमा के आगे गणना या कन्वर्ज़न मान को लपेट सकता है, अस्वीकार या काट सकता है, अथवा किसी अन्य कार्यान्वयन-विशिष्ट तरीके से विफल हो सकता है।

2147483648 का अर्थ प्रणाली पर निर्भर है

आधुनिक 64-बिट या मनचाही प्रिसीजन वाला पाथ उस क्षण को सामान्य रूप से दर्शा सकता है। पुराना signed-32-बिट उपभोक्ता नहीं कर सकता, इसलिए एक सार्वभौमिक लिपटी तारीख न मानें।

वास्तव में किन प्रणालियों को खतरा है

• पुराने time_t और C लाइब्रेरी पाथ
• लंबी सहायता अवधि वाले एम्बेडेड और औद्योगिक सॉफ़्टवेयर
• Epoch सेकंड को signed 32-बिट पूर्णांक के रूप में रखने वाले डेटाबेस फ़ील्ड
• निश्चित-चौड़ाई टाइमस्टैम्प फ़ील्ड वाले पुराने प्रोटोकॉल और बाइनरी प्रारूप

32-बिट बनाम 64-बिट केवल CPU आर्किटेक्चर नहीं है

ऐप ABI, प्रोग्रामिंग भाषा का प्रकार, डेटाबेस कॉलम, सीरियलाइज़ेशन प्रारूप और निर्भरता का व्यवहार आधुनिक हार्डवेयर पर भी सीमा लगा सकते हैं।

वर्ष 2038 बनाम Y2K

Y2K में दो-अंकीय वर्ष की धारणा थी; Y2K38 में निश्चित-चौड़ाई signed सेकंड का प्रतिनिधित्व है। दोनों तारीख के प्रतिनिधित्व संबंधी धारणाओं की विफलताएँ हैं, लेकिन मूल कारण अलग हैं।

डेवलपर समीक्षा सूची

• Signed 32-बिट epoch फ़ील्ड और कन्वर्ज़न खोजें।
• सीमा की और दूर भविष्य की तारीखें शुरू से अंत तक जाँचें।
• डेटाबेस, प्रोटोकॉल, निर्भरता और प्लेटफ़ॉर्म समर्थन की समीक्षा करें।
• सहेजे डेटा के लिए पीछे की अनुकूलता वाली माइग्रेशन योजना बनाएँ।

सीमा कैसे जाँचें

2147483647 और 2147483648 को सेकंड मानकर बदलें। आधुनिक टूल पास-पास के मान्य क्षण दिखा सकता है, जबकि पुराना उपभोक्ता ओवरफ़्लो करता है।

आम गलत धारणाएँ

• केवल आधुनिक हार्डवेयर ऐप की सुरक्षा की गारंटी नहीं देता।
• एक डेटाबेस कॉलम बदलने से हर सीरियलाइज़र और निर्भरता ठीक नहीं होती।
• हर ओवरफ़्लो समान लिपटी तारीख या विफलता नहीं देता।