هذه المقالة يتيمة. ساعد بإضافة وصلة إليها في مقالة متعلقة بها
تحتوي هذه المقالة أو أجزاء على نصوص مترجمة بحاجة مراجعة
يرجى تنسيق المقالة حسب أسلوب التنسيق المُتبع في ويكيبيديا.

معضلة العام 2038

من ويكيبيديا، الموسوعة الحرة
اذهب إلى التنقل اذهب إلى البحث
Edit-clear.svg
تعرَّف على طريقة التعامل مع هذه المسألة من أجل إزالة هذا القالب.هذه المقالة أو القسم تحتاج للتنسيق. فضلًا، ساهم بتنسيقها وفق دليل الأسلوب المعتمد في ويكيبيديا.
Edit-clear.svg
تعرَّف على طريقة التعامل مع هذه المسألة من أجل إزالة هذا القالب.تحتاج النصوص المترجمة في هذه المقالة إلى مراجعة لضمان معلوماتها وإسنادها وأسلوبها ومصطلحاتها ووضوحها للقارئ، لأنها تشمل ترجمة اقتراضية أو غير سليمة. فضلاً ساهم في تطوير هذه المقالة بمراجعة النصوص وإعادة صياغتها بما يتناسب مع دليل الأسلوب في ويكيبيديا.
صورة متحركة توضح الخطأ أثناء حدوثه. تجاوز السعة يحدث عند الساعة 03:14:08.

معضلة عام 2038 (المعروفة أيضًا باسم Y2038 ، [1] Y2K38 ، أو ايبوكلابيس[2] [3] ) هي خطأ برمجي في تنسيق الوقت في أنظمة الكمبيوتر ذات معمارية 32 بت عند محاولتها تمثيل الأوقات بعد الساعة 03:14:07 بالتوقيت العالمي المنسق في الـ19 يناير 2038.

تتواجد المشكلة في الأنظمة التي تقيس الوقت بنظام توقيت يونكس - حيث تُقاس عدد الثواني المنقضية منذ "عصر يونكس"والذي يكون منتصف الليل من 1 كانون الثاني 1970 حسب التوقيت العالمي المنسق (00:00:00 UTC في 1 يناير 1970) - ويكون تخزين عدد الثواني في نوع البيانات الذي يدعى "عدد صحيح بإشارة ذو حجم 32 بت". نوع البيانات هذا قادر فقط على تمثيل الأعداد الصحيحة بين سالب 231 ( 2 إلى قوة 31) وموجب 1 -231، مما يعني أن آخر وقت يمكن ترميزه هو 1 -231 ثانية بعد عصر يونكس والذي يكون (03:14:07 بالتوقيت العالمي المنسق في 19 يناير 2038) . ستؤدي محاولة تمثيل الثانية التالية (03:14:08) إلى تجاوز العدد الصحيح أي تجاوز القدرة التخزينية لنوع البيانات "عدد صحيح بإشارة ذو حجم 32 بت"، ما سيؤدي إلى حدوث خطأ يؤدي إلى تعيين قيمته لسالب 231 والتي ستفسرها الأنظمة على أنها 231 ثانية قبل عصر يونكس والذي سيكون (20:45:52 بالتوقيت العالمي المنسق في 13 ديسمبر 1901). إن المشكلة مشابهة في طبيعتها لمشكلة عام 2000 .

قد تواجه أنظمة الكمبيوتر التي تستخدم نظام توقيت يونكس للعمليات الهامة أخطاء فادحة إذا لم تتم حل معضلة Y2038 مبكرا. وقد واجهت بعض الأنظمة التي تستخدم التواريخ اللاحقة الأخطاء بالفعل. أكثر الأنظمة عرضة للأخطاء هي تلك التي نادرًا ما يتم تحديثها أو لا يتم تحديثها أبدًا، مثل الأنظمة القديمة والمدمجة . لا يوجد حل شامل لهذه المشكلة، لكنه تم بالفعل ترقية العديد من الأنظمة الحديثة لقياس وقت يونكس بأعداد صحيحة حسب معمارية 64 بت والتي لن يحدث بها تجاوز للسعة لـ292 مليار سنة.

السبب[عدل]

تقيس العديد من أنظمة الكمبيوتر الوقت والتاريخ على أنه وقت يونكس ، وهو معيار دولي لعرض الوقت رقميا. يتم تعريف وقت يونكس على أنه عدد الثواني المنقضية منذ منتصف الليل (00:00:00) بالتوقيت العالمي المنسق من 1 يناير 1970 ( تم اختيار هذا الوقت عشوائيًا من قبل المبرمجين) ، وأطلق على هذا الوقت اسم عصر يونكس.

تم ترميز وقت يونكس تاريخيًا باعتباره عددًا صحيحًا بإشارة ذو حجم 32 بت ( اسم آخر: عدد صحيح 32 بت بإشارة)، وهو نوع بيانات يتكون من 32 رقمًا ثنائيًا (بت) والتي تمثل قيمة عدد صحيح، حيث تعني كلمة "بإشارة" أن بت واحدة محجوزة لإشارة الموجب أو السالب (+/-). وبالتالي، يمكن أن يُمثِّل نوع البيانات "عدد صحيح بإشارة ذو حجم 32 بت" قيمًا صحيحة فقط من231 إلى 1 -231 ضمناً. وبالتالي، إذا تم استخدام عدد صحيح 32 بت بإشارة لتخزين وقت يونكس، فإن آخر وقت يمكن تخزينه هو 1 -231 = (2147483647) ثانية بعد عصر يونكس، والذي يكون 03:14:07 UTC في الـ19 يناير 2038. . [4] الأنظمة التي تحاول زيادة هذه القيمة بمقدار ثانية واحدة لتصل إلى 231 ثانية بعد الحقبة (03:14:08) ستعاني من تجاوز عدد صحيح ، مما يؤدي عن غير قصد إلى قلب بت الإشارة إلى سالب. يؤدي هذا إلى تغيير قيمة العدد الصحيح إلى سالب 231 ، أو 231 ثانية قبل عصر يونكس وليس بعده ، والتي ستفسرها الأنظمة على أنها الساعة 20:45:52 يوم الجمعة، 13 ديسمبر 1901. من هنا، ستستمر الأنظمة في العد التصاعدي، باتجاه الصفر (أي باتجاه عصر يونكس)، ثم لأعلى خلال الأعداد الصحيحة الموجبة مرة أخرى. نظرًا لأن العديد من أنظمة الكمبيوتر تستخدم حسابات الوقت لتشغيل وظائف مهمة، فقد تؤدي المعضلة إلى حدوث أخطاء فادحة.

انظر أيضا[عدل]

مراجع[عدل]

  1. ^ "Is the Year 2038 problem the new Y2K bug?"، The Guardian، 17 ديسمبر 2014، مؤرشف من الأصل في 25 يناير 2022، اطلع عليه بتاريخ 11 أكتوبر 2018.
  2. ^ Bergmann, Arnd (6 فبراير 2020)، "The end of an Era"، Linaro، مؤرشف من الأصل في 18 أبريل 2021.
  3. ^ Wagenseil, Paul (28 يوليو 2017)، "Digital 'Epochalypse' Could Bring World to Grinding Halt"، Tom's Guide، مؤرشف من الأصل في 29 نوفمبر 2021.
  4. ^ Diomidis Spinellis (2006)، Code quality: the open source perspective، Effective software development series in أوريلي ميديا (ط. illustrated)، Adobe Press، ص. 49، ISBN 978-0-321-16607-4، مؤرشف من الأصل في 18 مايو 2021.