أخطاء تنسيق الوقت والتخزين

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

في 5 يناير 1975، فاض الحقل المكون من 12 بت والذي كان يستخدم للتواريخ في نظام التشغيل TOPS-10 لأجهزة الكمبيوتر DEC PDP-10 ، في خطأ يُعرف باسم "DATE75". تم حساب قيمة الحقل عن طريق أخذ عدد السنوات منذ عام 1964، وضربها في 12، وإضافة عدد الأشهر منذ يناير، وضربها في 31، وإضافة عدد الأيام منذ بداية الشهر؛ ووضع هذا في يعطي 4 يناير 1975، وهو بالتالي أحدث تاريخ قابل للترميز. دفعت تصحيح "DATE-75" آخر تاريخ قابل للترميز إلى 1 فبراير 2052، مما يجعل تاريخ الفائض 2 فبراير 2052، باستخدام 3 بتات احتياطية من حقول أخرى في بيانات التعريف الخاصة بنظام الملفات ، ولكن هذا تسبب أحيانًا في حدوث مشكلات مع البرامج التي تستخدم تلك البتات لأغراضها الخاصة. ربما كانت بعض البرامج تدعم استخدام بت إضافي واحد للتاريخ ولكنها واجهت مشكلات مع البتات الإضافية، مما قد يؤدي إلى بعض الأخطاء في 9 يناير 1986. ^{[1] [2] [3] [4]}${\displaystyle 2^{12}-1=4095}$

استخدم نظام التشغيل OS/8 من شركة Digital Equipment Corporation لجهاز الكمبيوتر PDP-8 ثلاثة بتات فقط للسنة، تمثل الأعوام من 1970 إلى 1977. ^[5]

تم التعرف على ذلك عند تطوير نظام التشغيل COS-310 ، وتم تسجيل التواريخ بشكل مختلف. ^[6]

بدأت العديد من ألعاب Sierra Entertainment التي تم إصدارها لنظام التشغيل Classic Mac OS في التجميد عند التشغيل في 18 سبتمبر 1993. كانت هناك مشكلة في إصدار Mac من Sierra's Creative Interpreter (Mac SCI) من شأنها أن تتسبب في "توقف" اللعبة عند محاولة التعامل مع تأخير بسبب مشكلة تتعلق بفيض. سيحاول Mac SCI استخدام التاريخ لتحديد المدة التي يجب أن يستمر فيها التأخير من خلال الحصول على الوقت الحالي بالثواني منذ 1 يناير 1904، عصر Macintosh، وقسمته على 12 ساعة. تمت معالجة القسمة بواسطة Motorola 68000 ولن تحدث إذا تم اكتشاف فيض بسبب القسمة، لكن Mac SCI سيستمر بغض النظر عن ذلك كما لو كان القسمة قد حدثت، مما يؤدي في النهاية إلى معاملة تأخير لمدة ثانية واحدة على أنه تأخير لمدة 18 ساعة وما إلى ذلك. أصدرت Sierra تصحيحًا يسمى MCDATE حل المشكلة لمدة 14 عامًا تقريبًا. ^{[7] [8]}

لقد تجاوزت ساعة المجال /نظام التشغيل ، والتي تعتمد على عدد وحدات 4 ميكروثانية التي حدثت منذ 1 يناير 1980، 47 بتًا في 2 نوفمبر 1997، مما جعل الأنظمة غير المرقعة غير قابلة للاستخدام. ^[9]

وفي الأشهر القليلة الماضية قبل عام 2000، حدثت حدثان مهمان آخران مرتبطان بالتاريخ، وقد حظيا بقدر أقل من الدعاية التي حظيت بها مشكلة عام 2000 التي كانت وشيكة آنذاك.

يتم التعبير عن تواريخ نظام تحديد المواقع العالمي (GPS) كرقم أسبوع ورقم يوم من أيام الأسبوع، مع إرسال رقم الأسبوع كقيمة مكونة من عشرة بتات . وهذا يعني أنه كل 1024 أسبوعًا (حوالي 19.6 عامًا) بعد يوم الأحد 6 يناير 1980 ( عصر نظام تحديد المواقع العالمي (GPS ))، يتم إعادة تعيين التاريخ مرة أخرى إلى ذلك التاريخ؛ حدث هذا لأول مرة في الساعة 23:59:47 يوم 21 أغسطس 1999، ^[10] والمرة الثانية في الساعة 23:59:42 بالتوقيت العالمي المنسق يوم 6 أبريل 2019، وسيحدث مرة أخرى في 20 نوفمبر 2038. ^[11] لمعالجة هذا القلق، تستخدم رسائل الملاحة بنظام تحديد المواقع العالمي (GPS) الحديثة حقلًا مكونًا من 13 بتًا، والذي يتكرر فقط كل 8192 أسبوعًا (157 عامًا)، ولن يعود إلى الصفر حتى عام 2137. ^[12]

استخدمت العديد من البرامج أو مجموعات البيانات القديمة "9/9/99" كقيمة غير قانونية للإشارة إلى تاريخ غير محدد أو كعلامة إنهاء للإشارة إلى عدم وجود المزيد من البيانات في المجموعة. وقد تسبب هذا في تعطل العديد من الأنظمة عند وصول التاريخ الفعلي الذي يمثله، 9 سبتمبر 1999. ^[10]

يشير مصطلح مشكلة عام 2000، أو Y2K ببساطة، إلى الأخطاء المحتملة في الكمبيوتر المتعلقة بتنسيق وتخزين بيانات التقويم للتواريخ في عام 2000 وما بعده. تمثل العديد من البرامج سنوات مكونة من أربعة أرقام مع الرقمين الأخيرين فقط، مما يجعل عام 2000 غير قابل للتمييز عن عام 1900. كان عدم قدرة أنظمة الكمبيوتر على التمييز بين التواريخ بشكل صحيح من المحتمل أن يؤدي إلى انهيار البنية التحتية العالمية للصناعات المعتمدة على الكمبيوتر.

بالنسبة للتطبيقات المطلوبة لحساب سنة الميلاد (أو سنة ماضية أخرى)، فقد تم استخدام مثل هذه الخوارزمية منذ فترة طويلة للتغلب على مشكلة عام 1900 ، لكنها فشلت في التعرف على الأشخاص الذين تزيد أعمارهم عن 100 عام .

واجهت الأنظمة التي استخدمت سلسلة من تسعة أرقام لتسجيل الوقت بالثواني منذ بداية عصر يونكس مشكلات في الإبلاغ عن الأوقات التي تجاوزت المليار ثانية بعد بداية العصر في 9 سبتمبر 2001 الساعة 01:46:40 (المليار). لم تكن المشكلات منتشرة على نطاق واسع. ^[13]

تبدأ ألعاب Sierra Entertainment لنظام التشغيل Mac OS الكلاسيكي التي تم تصحيحها باستخدام برنامج MCDATE أو التي تم إصدارها بعد ذلك مع التصحيح المدمج في التجميد في 28 مايو 2007. وكما حدث مع مشكلة عام 1993، كان هذا بسبب مشكلة في Mac SCI عند محاولة استخدام التاريخ لتحديد المدة التي يجب أن يستمر فيها التأخير. تتجمد البرامج التي تحتوي على تصحيح MCDATE لأن Mac SCI يأخذ عدد الثواني الحالي منذ عصر Macintosh في 1 يناير 1904، ويطرح 432،000،000 ثانية من ذلك، ثم يقسم على 12 ساعة من خلال Motorola 68000، لتحديد المدة التي يجب أن تستمر فيها التأخيرات. في 28 مايو 2007، لم يقسم Motorola 68000 مرة أخرى بسبب حماية الفائض، والتي يتجاهلها Mac SCI. ^[7]

واجهت بعض الأنظمة مشكلات بمجرد حلول العام 2010. وقد أطلق البعض في وسائل الإعلام على هذه المشكلة اسم "مشكلة عام 2000+10" أو "مشكلة عام 2010+2010". ^[14]

كان المصدر الرئيسي للمشاكل هو الارتباك بين ترميز الأرقام السداسية عشرية وترميز BCD للأرقام. يتم ترميز الأرقام من 0 إلى 9 في كل من النظام السداسي عشر ونظام BCD على النحو التالي: 00 ₁₆ إلى 09 _16. ولكن يتم ترميز الرقم العشري 10 في النظام السداسي عشر على النحو التالي: 0A ₁₆ وفي نظام BCD على النحو التالي: 10 _16. وبالتالي، فإن ترميز BCD 10 ₁₆ الذي يتم تفسيره على أنه ترميز سداسي عشري يمثل الرقم العشري 16 بشكل خاطئ.

على سبيل المثال، يستخدم بروتوكول الرسائل القصيرة ترميز BCD للتواريخ، لذلك أبلغت بعض برامج الهاتف المحمول عن تواريخ الرسائل بشكل غير صحيح على أنها 2016 بدلاً من 2010. كان Windows Mobile هو أول برنامج تم الإبلاغ عن تأثره بهذا الخلل؛ في بعض الحالات، قام WM6 بتغيير تاريخ أي رسالة SMS واردة تم إرسالها بعد 1 يناير 2010، من عام 2010 إلى عام 2016. ^{[15] [16]}

تشمل الأنظمة الأخرى المتأثرة محطات EFTPOS ، ^[17] و PlayStation 3 (باستثناء طراز Slim). ^[18]

لقد تعاملت بلاي ستيشن 3 من سوني بشكل غير صحيح مع عام 2010 على أنه سنة كبيسة ، لذلك تم عرض التاريخ غير الموجود 29 فبراير 2010 في 1 مارس 2010، مما تسبب في حدوث خطأ في البرنامج . ^[19]

وقد حدث الخلل الأكثر أهمية في ألمانيا، حيث أصبح ما يزيد عن 20 مليون بطاقة مصرفية غير صالحة للاستخدام، وفي بنك سيتي بنك بلجيكا، الذي توقفت شرائح تحديد هوية العملاء الخاصة به عن العمل. ^[20]

تستخدم تايوان رسميًا تقويم مينجو ، والذي يعتبر السنة الميلادية 1912 هي عامها الأول. وبالتالي، فإن السنة الميلادية 2011 هي سنة 100 في جمهورية الصين، وهي أول سنة مكونة من 3 أرقام. ^[21] وهذا يجعل السنة تبدو وكأنها 1911 (السنة 0) إذا تم استخدام تمثيلات مكونة من رقمين.

فقد مسبار الفضاء ديب إمباكت الاتصال بالأرض في 11 أغسطس 2013، بسبب مشكلة في تحديد الوقت؛ حيث تم تخزين التاريخ كعدد صحيح غير موقّع مكون من 32 بتًا يحسب عدد الأجزاء من عشر الثواني منذ 1 يناير 2000. ^[22]

في عام 2019، حدث تغيير رقم أسبوع نظام تحديد المواقع العالمي للمرة الثانية . لم يعد بإمكان تلسكوب Meade المحوسب المزود بنظام تحديد المواقع العالمي (GPS) مثل LX200GPS العثور على موقعه وبالتالي لم يعد بإمكانه محاذاة نفسه أو تحديد موقع الأجرام النجمية. أصدرت Meade برنامجًا ثابتًا جديدًا 4.2k مع إصلاح ولكنه قدم أيضًا العديد من الأخطاء الجديدة. تم إصدار 4.2l (L الصغير، والذي غالبًا ما يتم الخلط بينه وبين I) لإصلاح ذلك، ولكن كان به تغييرات أكثر غموضًا. أصدرت جهة خارجية، StarPatch، إصدارًا مخترقًا من البرنامج الثابت 4.2g مجانًا لإصلاح المشكلات.

في 30 أبريل 2019، تنازل الإمبراطور أكيهيتو عن العرش لصالح ابنه ناروهيتو . ونظرًا لأن السنوات في اليابان يشار إليها تقليديًا بأسماء العصور التي تتوافق مع عهد كل إمبراطور، فقد أدى هذا إلى اسم عصر جديد، ريوا (令和) ، بعد تولي ناروهيتو العرش في اليوم التالي. نظرًا لأن الإمبراطور السابق، هيروهيتو ، توفي في 7 يناير 1989، وتوافق عهد أكيهيتو في الغالب مع زيادة استخدام أجهزة الكمبيوتر، لم يتم اختبار معظم البرامج لضمان السلوك الصحيح عند تغيير العصر، في حين تعقد الاختبار بسبب حقيقة أن اسم العصر الجديد لم يتم الكشف عنه حتى 1 أبريل 2019. لذلك، كان من المتوقع حدوث أخطاء من البرامج التي لم تتوقع عصرًا جديدًا.

تعطلت كل من ألعاب الفيديو WWE 2K20 و Star Wars Jedi: Fallen Order في الأول من يناير 2020، عندما انتهى العام. ولم يكن من الممكن التغلب على هذه المشكلات إلا بإعادة ضبط العام إلى عام 2019 حتى يتم إصدار التصحيح. ^{[23] [24]} بالإضافة إلى ذلك، فشل Crystal Reports 8.5 في إنشاء تقارير محددة بدءًا من عام 2020. ^[25]

لم تتمكن عدادات مواقف السيارات التابعة لشركة باركيون في مدينة نيويورك والمواقع الأخرى من قبول بطاقات الائتمان كشكل من أشكال الدفع بدءًا من عام 2020. تم تنفيذ حل بديل، لكنه يتطلب تحديث كل عداد على حدة. في نيويورك، لم يكن من المتوقع إصلاح العدادات حتى 9 يناير. ^{[26] [27]}

في بولندا، توقفت 5000 ماكينة تسجيل المدفوعات النقدية عن طباعة التاريخ بشكل صحيح. ^[28]

أظهرت ساعات Suunto الرياضية الذكية خطأً في حساب أيام الأسبوع التي تم تقديمها بخطوة +2 (على سبيل المثال الجمعة بدلاً من الأربعاء، والسبت بدلاً من الخميس). بالنسبة لساعات Suunto Spartan، تم إصلاح الخلل بإصدار البرنامج الثابت 2.8.32. ^[29]

لا تسمح لوحة التحكم في إصدارات Classic Mac OS 6 و7 و8 إلا بتعيين التاريخ على 31 ديسمبر 2019، على الرغم من أن النظام قادر على الاستمرار في تقديم الوقت بعد هذا التاريخ. ^{[30] [31]}

سترفض النسخة الأولى من Microsoft Schedule+ المرفقة مع الإصدار 3.0 من عميل البريد الإلكتروني Microsoft Mail العمل مع السنوات الأكبر من عام 2020 أو ما بعده، وذلك لأن البرنامج صُمم للعمل ضمن إطار زمني مدته 100 عام يتراوح من عام 1920 إلى عام 2019. ونتيجة لذلك، لا يمكن تعيين التاريخ إلا على 31 ديسمبر 2019. ^[32]

أبلغ مستخدمو Samsung أن الهواتف التي تعمل بأحدث تحديث One UI 3.0 أو Android 11 فقدت الوصول إلى إحصائيات البطارية والشحن بدءًا من عام 2021. لن تبلغ الأجهزة المتأثرة بإحصائيات الاستخدام، وبالتالي تترك هذه الأقسام فارغة. ^{[33] [34]}

التواريخ المخزنة بتنسيق yymmddHHMM المحولة إلى عدد صحيح مكون من 32 بت موقّع تجاوزت الحد في 1 يناير 2022، حيث 2 ³¹ = 2147483648. وكان من أبرز المتأثرين أرقام تحديث مكون فحص البرامج الضارة في Microsoft Exchange ، والتي يبدو أنها تُستخدم لإجراء فحص رياضي لتحديد أحدث تحديث. ^{[35] [36]}

أظهرت سيارات هوندا وأكورا المصنعة بين عامي 2004 و2012 والمحتوية على أنظمة ملاحة GPS بشكل غير صحيح أن العام هو 2002. كانت هذه المشكلة بسبب فيض في عصر GPS. ^{[37] [38]} تم حل المشكلة في 17 أغسطس 2022. ^[39]

لم يتمكن قارئو بطاقات الدفع في مضخات البنزين في نيوزيلندا من التعامل مع السنة الكبيسة ولم يتمكنوا من توزيع البنزين بشكل صحيح. ^[40]

عانت ألعاب الفيديو EA Sports WRC و Theatrhythm Final Bar Line أيضًا من مشكلات تتعلق بالسنة الكبيسة، حيث تعطلت الأولى عند محاولة تحميل اللعبة وزعمت الثانية أن بيانات الحفظ تالفة. كان لابد من ضبط كلتا اللعبتين على اليوم التالي 1 مارس 2024 للعمل بشكل صحيح. ^{[41] [42] [43]}

في اليابان، لا تزال بعض أنظمة الكمبيوتر القديمة التي تستخدم التقويم الياباني والتي لم يتم تحديثها تحسب السنوات وفقًا لعصر شووا . يتوافق عام 2025 في تلك الأنظمة مع شووا 100، وهو ما قد يسبب مشاكل إذا افترض البرنامج رقمين للسنة. ^[44]

تخزن بعض الأنظمة عامها كإزاحة بايت واحد من عام 1900، مما يعطي نطاقًا يبلغ 255 (8 بت) ويسمح بتمثيل التواريخ حتى عام 2155 بأمان. ومع ذلك، لا تستخدم جميع الأنظمة بايتًا غير موقّع : فقد تم ترميز بعضها عن طريق الخطأ باستخدام بايت موقّع يسمح فقط بنطاق 127 عامًا، مما يعني أن حقل التاريخ في البرنامج سيكون غير صحيح بعد عام 2027 ويمكن أن يتسبب في سلوك غير متوقع. تتأثر العديد من برامج الأقراص الضوئية التي تعمل باستخدام تنسيق ISO 9660 بهذا. ^[45]

خلال أواخر سبعينيات القرن العشرين، على أنظمة Data General Nova وEclipse، أنشأت شركة World Computer Corporation (التي تقدم طلبات اتحادات الائتمان) تنسيقًا للتاريخ بحقل تاريخ مكون من 16 بتًا لمدة 128 عامًا (7 بتات - لاحظ 1900+128=2028)، و12 شهرًا (4 بتات) و31 يومًا (5 بتات). سمح هذا بمقارنة التواريخ بشكل مباشر باستخدام وظائف غير موقعة. لا تزال بعض الأنظمة، بما في ذلك HP 3000 ، تستخدم هذا التنسيق، على الرغم من تطوير تصحيح بواسطة مستشارين خارجيين. ^[46]

يستخدم Palm OS كلًا من الأعداد الصحيحة الموقعة مع حقبة 1970 ، وكذلك الأعداد الصحيحة غير الموقعة مع حقبة 1904، لوظائف النظام المختلفة، ^[47] مثل ساعة النظام وتواريخ الملفات (انظر تنسيق PDB ). في حين أن هذا من شأنه أن يؤدي إلى تعرض Palm OS لمشكلة 2038، فإن Palm OS يستخدم أيضًا حقلًا مكونًا من 7 بتات لتخزين قيمة العام، مع حساب حقبة مختلفة عن 1904، مما يؤدي إلى عام أقصى هو 2031 (1904 + 127). ^[48]

بروتوكول وقت الشبكة لديه مشكلة فيضان تتعلق بمشكلة عام 2038 ، والتي تظهر في الساعة 06:28:16 بتوقيت UTC في 7 فبراير 2036، وليس 2038. تتكون الطوابع الزمنية المكونة من 64 بت والتي يستخدمها بروتوكول وقت الشبكة من جزء مكون من 32 بت للثواني وجزء مكون من 32 بت للجزء الكسري من الثانية، مما يمنح بروتوكول وقت الشبكة مقياسًا زمنيًا يتكرر كل 2 ³² ثانية (136 عامًا) ودقة نظرية تبلغ 2 ⁻³² ثانية (233 بيكو ثانية). يستخدم بروتوكول وقت الشبكة حقبة 1 يناير 1900. يحدث التكرار الأول في عام 2036، قبل مشكلة عام 2038 في يونكس. ^{[49] [50]}

كان التنفيذ الأصلي لنظام التشغيل يونكس يخزن وقت النظام كعدد صحيح موقّع مكون من 32 بت يمثل عدد الثواني بعد انتهاء عصر يونكس (1 يناير 1970، 00:00:00 UTC). وستنتقل هذه القيمة بعد 19 يناير 2038، 03:14:07 UTC. وقد تم معالجة هذه المشكلة في معظم أنظمة التشغيل يونكس الحديثة وأنظمة التشغيل الشبيهة بيونكس من خلال تخزين وقت النظام كعدد صحيح موقّع مكون من 64 بت، على الرغم من ضرورة تغيير التطبيقات والبروتوكولات وتنسيقات الملفات الفردية أيضًا.

كما هو الحال مع مشكلة ترحيل وقت يونكس، فإن الإصدار 32 بت من gmtime في مكتبات وقت التشغيل C على Windows لديه مشكلة مماثلة. ^[51]

وقد ظهرت هذه المشكلة بالفعل في إصدار 10.1.4.3 من برنامج Access Manager من Oracle لنظام التشغيل Windows. حيث يقوم مكون Identity Console بتعيين ملف تعريف ارتباط يحتوي على تفضيلات واجهة المستخدم مع انتهاء صلاحية 500,000,000 ثانية في المستقبل (حوالي 16 عامًا). وهذا بعد 19 يناير 2038، وبالتالي فإنه يطرح استثناءً لأنشطة بحث معينة بعد الساعة 02:20:48 بالتوقيت العالمي المنسق في 17 مارس 2022 لأن استدعاء gmtime_r() لا يمكنه تحويل الرقم المقدم إلى تاريخ للكتابة في ملف تعريف الارتباط. ^[52] وعلى الرغم من عمر البرنامج (18 يونيو 2009)، فقد أصدرت Oracle رقم التصحيح 33983548 في 6 أبريل 2022.

سيحدث تغيير رقم أسبوع GPS الثالث في 20 نوفمبر 2038، الساعة 23:59:37 بالتوقيت العالمي المنسق.

تخزن أجهزة كمبيوتر Apple Macintosh المبكرة الوقت في ساعات الوقت الحقيقي (RTCs) وأنظمة الملفات HFS كعدد غير موقّع من الثواني مكون من 32 بت منذ 00:00:00 في 1 يناير 1904. بعد 06:28:15 في 6 فبراير 2040، (أي 2 ³² −1 ثانية من العصر)، سينتقل هذا إلى 1904: ^[53] بالإضافة إلى ذلك، يتأثر أيضًا HFS+ ، التنسيق الافتراضي لجميع أجهزة كمبيوتر Apple Macintosh الحديثة. يحل نظام ملفات Apple البديل هذه المشكلة.

يدعم برنامج ProDOS لأجهزة كمبيوتر Apple II أرقام السنوات المكونة من رقمين فقط. لتجنب مشكلات عام 2000، أصدرت Apple ملاحظة فنية تنص على أن رقم السنة يجب أن يمثل الفترة من 1940 إلى 2039. ^[54] قد يعرض برنامج النظام الأساسي بشكل غير صحيح التواريخ التي تبدأ في عام 2040، على الرغم من أن جهدًا من جهة خارجية جارٍ لتحديث برنامج ProDOS وبرامج التطبيق لدعم السنوات حتى 4095. ^[55]

في 18 سبتمبر 2042، سيتم تغيير ساعة الوقت (TODC) على الحاسوب المركزي S/370 من إنتاج شركة IBM وخلفائه، بما في ذلك سلسلة zSeries الحالية. ^[56]

تم تنفيذ TODCs الأقدم كعدد 64 بت من وحدات 2 ⁻¹² ميكروثانية (0.244 نانوثانية)، وكانت القاعدة القياسية هي 1 يناير 1900، بالتوقيت العالمي المنسق . في يوليو 1999، تم الإعلان عن ساعة TODC الممتدة، والتي مددت الساعة إلى اليمين (أي أن البتات الممتدة أقل أهمية من البتات الأصلية). يعتمد الدقة الفعلية على النموذج، ولكن التنسيق متسق، وبالتالي سيتم ترحيله بعد 2 ⁵² ميكروثانية. ^[56]

قيمة TODC يمكن الوصول إليها من خلال برامج وضع المستخدم ويتم استخدامها غالبًا للتوقيت وإنشاء معرفات فريدة للأحداث.

في حين قامت شركة IBM بتعريف وتنفيذ تنسيق أجهزة أطول (128 بت) على الأجهزة الحديثة، والذي يمتد المؤقت على كلا الطرفين بما لا يقل عن 8 بتات إضافية، فإن العديد من البرامج لا تزال تعتمد على تنسيق 64 بت الذي يظل بمثابة مجموعة فرعية يمكن الوصول إليها من المؤقت الأطول.

يدعم منطق تخطيط السعة في نظام تخطيط موارد المؤسسات SAP S/4HANA تواريخ الانتهاء حتى 19 يناير 2048 فقط (24855 يومًا من 1 يناير 1980، وهو ما يعادل 2.31 ^ثانية تقريبًا إلى أيام كاملة). ويتعلق هذا على سبيل المثال بتخطيط الإنتاج والصيانة والتفتيش. ^[57]

وفقًا لمواصفات UNIX الموحدة لتحليل السنوات المكونة من رقمين باستخدام strptime()، "القيم في النطاق [69,99] يجب أن تشير إلى السنوات من 1969 إلى 1999 شاملة والقيم في النطاق [00,68] يجب أن تشير إلى السنوات من 2000 إلى 2068 شاملة"، ^[58] وهذا يعني أنه عند التحليل بواسطة strptime()، سيتم تفسير السنة المكونة من رقمين "69" على أنها 1969 وليس 2069.

البرامج التي تخزن التواريخ على أنها عدد الأيام منذ تاريخ (أو حقبة ) عشوائية تكون عرضة لتأثيرات التدحرج أو الالتفاف إذا لم تكن القيم واسعة بما يكفي للسماح لقيم التاريخ بتغطية نطاق زمني كبير بما يكفي متوقع للتطبيق. تتدحرج القيم الثنائية الموقعة المكونة من 16 بت بعد 32768 (2 ¹⁵ ) يومًا من تاريخ الحقبة، مما ينتج عنه قيم سلبية. واجهت بعض أنظمة الحاسبات المركزية أعطالًا في البرامج لأنها قامت بترميز التواريخ على أنها عدد الأيام منذ 1 يناير 1900، مما أدى إلى إنتاج أرقام أيام سلبية غير متوقعة في تاريخ التدحرج 18 سبتمبر 1989. وبالمثل، تتدفق أعداد الأيام الثنائية غير الموقعة المكونة من 16 بت بعد 65536 (2 ¹⁶ ) يومًا، والتي يتم اقتطاعها إلى قيم صفرية. بالنسبة للبرامج التي تستخدم حقبة 1 يناير 1900، سيحدث هذا في 6 يونيو 2079. ^[59]

تدعم بعض (إن لم يكن جميع) هواتف نوكيا التي تعمل بنظام التشغيل Series 40 (مثل Nokia X2-00 ) التواريخ حتى 31 ديسمبر 2079 فقط، وبالتالي لن تتمكن من عرض التواريخ بعد هذا التاريخ. أحد الحلول البديلة هو استخدام عام 1996 أو 2024 أو 2052 بدلاً من 2080 (كسنوات كبيسة متوافقة) لعرض يوم الأسبوع والتاريخ والشهر الصحيحين على الشاشة الرئيسية. ^{[ بحاجة لمصدر ]}

قد يتم ترحيل الأنظمة التي تخزن السنة كقيمة مكونة من رقمين 00..99 داخليًا فقط، مثل العديد من أنظمة RTC، من 31 ديسمبر 2079 إلى عصر IBM PC وDOS في 1980-01-01 .

لا يستشهد هذا القسم بأي مصادر . يُرجى المساعدة في تحسين هذا القسم من خلال إضافة الاستشهادات إلى مصادر موثوقة . قد يتم الطعن في المواد غير الموثقة وإزالتها . ( أغسطس 2021 ) ( تعرف على كيفية ومتى يمكنك إزالة هذه الرسالة )

تدعم واجهة برمجة تطبيقات تاريخ الملفات ووظائف التحويل (مثل INT 21h /AH=2Ah) في نظامي التشغيل DOS و Windows التواريخ حتى 31 ديسمبر 2099 رسميًا فقط (على الرغم من أن نظام الملفات FAT الأساسي يدعم نظريًا التواريخ حتى 2107). وبالتالي، قد تظهر أنظمة التشغيل المستندة إلى DOS، بالإضافة إلى التطبيقات التي تحول التنسيقات الأخرى إلى تنسيق FAT/DOS، سلوكًا غير متوقع بدءًا من 1 يناير 2100.

وعلى نحو مماثل، فإن أجهزة Nintendo DS وGameCube، فضلاً عن Sony PlayStation 4، تسمح للمستخدمين بتعيين تواريخ حتى عام 2099 فقط. وفي حالة Nintendo DS، لن يقدم النظام الوقت إلى ما بعد 31 ديسمبر/كانون الأول 2099، في حين أن GameCube وPS4 سوف يستمران في التقدم إلى عام 2100 وما بعده، على الرغم من أن مستخدمي هذه الأجهزة لا يمكنهم إدخال التاريخ والوقت يدويًا إلى هذا الحد.

ستظهر مشكلة أخرى في نهاية 28 فبراير 2100، لأن 2100 ليست سنة كبيسة . ونظرًا لأن العديد من التطبيقات الشائعة لخوارزمية السنة الكبيسة غير مكتملة أو مبسطة، فقد تفترض خطأً أن 2100 سنة كبيسة، مما يتسبب في ترحيل التاريخ من 28 فبراير 2100 إلى 29 فبراير 2100، بدلاً من 1 مارس 2100.

تستخدم العديد من تنسيقات الملفات وبروتوكولات الاتصالات وواجهات التطبيقات الحالية شكلًا مختلفًا من تنسيق تاريخ يونكس time_t ، حيث يتم تخزين عدد الثواني منذ بداية يونكس (منتصف الليل بتوقيت جرينتش، 1 يناير 1970) كعدد صحيح ثنائي غير موقّع مكون من 32 بت. سيتم ترحيل هذه القيمة في 7 فبراير 2106 الساعة 06:28:15 بتوقيت جرينتش. أي أن عدد الثواني منذ 1 يناير 1970 في هذا الوقت هو FFFF FFFF بالنظام السداسي عشر.

تعتبر مشكلة تمثيل التخزين هذه مستقلة عن البرامج التي تخزن داخليًا أوقات النظام وتعمل عليها كقيم صحيحة موقعة مكونة من 64 بت.

ستفيض طوابع التاريخ المخزنة في أنظمة الملفات FAT ، والتي تم تقديمها في الأصل مع إصدار 86-DOS 0.42 في عام 1981 وتم نقلها إلى MS-DOS و PC DOS و DR-DOS وما إلى ذلك، في نهاية 31 ديسمبر 2107. يتم تخزين ختم تاريخ التعديل الأخير (ومع DELWATCH 2.0+ أيضًا ختم تاريخ حذف الملف ، ومنذ DOS 7.0 + اختياريًا أيضًا ختم تاريخ آخر وصول وختم تاريخ الإنشاء )، في إدخال الدليل مع تمثيل السنة كرقم غير موقّع مكون من سبعة بتات (0-127)، نسبة إلى عام 1980، وبالتالي لا يمكن الإشارة إلى أي تواريخ في عام 2108 وما بعده. تدعم وظائف واجهة برمجة التطبيقات المحددة لاسترداد هذه التواريخ رسميًا التواريخ حتى 31 ديسمبر 2099 فقط.

سيؤثر هذا أيضًا على تنسيق ملف أرشيف ZIP ، لأنه يستخدم طوابع زمنية لتعديل ملف FAT داخليًا.

يتم التعبير عن تواريخ نظام تحديد المواقع العالمي (GPS) برقم أسبوع ورقم يوم من أيام الأسبوع، حيث يستخدم رقم الأسبوع في البداية قيمة مكونة من عشرة بتات ، وتستخدم رسائل الملاحة بنظام تحديد المواقع العالمي (GPS) الحديثة حقلًا مكونًا من 13 بتًا. ستنتقل الأنظمة المكونة من عشرة بتات كل 1024 أسبوعًا (حوالي 19.6 عامًا) بعد يوم الأحد 6 يناير 1980 ( عصر نظام تحديد المواقع العالمي )، وستنتقل الأنظمة المكونة من 13 بتًا كل 8192 أسبوعًا. ستنتقل الأنظمة المكونة من ثلاثة عشر بتًا إلى الصفر في عام 2137. ^{[10] [11]}

يخزن نظام التشغيل RISC OS التواريخ بوحدات سنتي ثانية منذ الأول من يناير 1900 في خمسة بايتات - 40 بت. تُستخدم هذه الطوابع الزمنية داخليًا وتُعرض في بيانات تعريف الملف (عناوين التحميل والتنفيذ). ^[60] تنتهي هذه الفترة في 3 يونيو 2248 الساعة 06:57:57.75 بالتوقيت العالمي المنسق.

بعض أنظمة قياس الوقت عالية الدقة تحسب النانو ثانية منذ 1 يناير 1970 باستخدام عدد صحيح موقّع مكون من 64 بت، والذي سيتجاوز الحد الأقصى في 11 أبريل 2262 في الساعة 23:47:16 بالتوقيت العالمي المنسق. واجهة برمجة تطبيقات لغة البرمجة Go UnixNano هي أحد الأمثلة. ^[61] تشمل الأمثلة الأخرى كائن Timestamp في Python pandas ، ^[62] والفئة chronoفي C++ عند ضبطها على دقة النانو ثانية، ^[63] ومؤقتات QEMU . ^[64]

قد تواجه الأنظمة التي تستخدم سلسلة من 10 أحرف بطول لتسجيل وقت يونكس مشاكل في الإبلاغ عن الأوقات التي تتجاوز 20 نوفمبر 2286، في الساعة 17:46:39، أي عشرة مليارات ثانية بعد عصر يونكس.

في نظام الملفات ext4 ، وهو نظام الملفات الافتراضي للعديد من توزيعات لينكس، يتم استخدام البتاتين السفليتين {a,c,m}time_extraلتمديد {a,c,m}timeالحقول، مما يؤدي إلى تأجيل مشكلة عام 2038 إلى عام 2446. ^[65] داخل هذا الحقل "الإضافي" المكون من 32 بت، يتم استخدام البتاتين السفليتين لتمديد حقل الثواني إلى عدد صحيح مكون من 34 بت؛ يتم استخدام البتات الثلاثين العلوية لتوفير دقة الطابع الزمني بالنانوثانية. لذلك، لن تفيض الطوابع الزمنية حتى مايو 2446. ^[66]

على مقاييس زمنية تمتد لآلاف السنين، يتأخر التقويم الغريغوري عن المواسم الفلكية. وذلك لأن سرعة دوران الأرض تتباطأ تدريجيًا ، مما يجعل كل يوم أطول قليلاً بمرور الوقت (انظر تسارع المد والجزر والثانية الكبيسة ) بينما تحافظ السنة على مدة أكثر اتساقًا.

في القرن التاسع عشر، اقترح السير جون هيرشل تعديلاً على التقويم الغريغوري بإضافة 969 يومًا كبيسًا كل 4000 عام، بدلاً من 970 يومًا كبيسًا يضيفها التقويم الغريغوري خلال نفس الفترة. ^[67] سيؤدي هذا إلى تقليل متوسط ​​السنة إلى 365.24225 يومًا. سيجعل اقتراح هيرشل سنة 4000 ومضاعفاتها سنة مشتركة بدلاً من سنة كبيسة. في حين تم اقتراح هذا التعديل كثيرًا منذ ذلك الحين، إلا أنه لم يتم اعتماده رسميًا أبدًا. ^[68]

في حين أن معظم البرامج (بما في ذلك Excel و JavaScript و R ) تتعرف حاليًا على 4000 و8000 كسنوات كبيسة (لأنها قابلة للقسمة على 400)، فقد تبنت SAS "قاعدة 4000 عام". وبالتالي، مع البرنامج الحالي، ستصبح تحويلات التاريخ بين SAS والبرامج الأخرى غير متزامنة بعد 28 فبراير 4000. ^{[69] [70]}

يستخدم Microsoft Outlook التاريخ 1 يناير 4501 كعلامة مكانية لـ "لا شيء" أو "فارغ". ^{[71] [72]}

ستكون سنة 10000 هي أول سنة ميلادية مكونة من خمسة أرقام. تواجه جميع السنوات المستقبلية التي تكون قوى العدد 10، وكذلك التواريخ قبل الألفية العاشرة قبل الميلاد ، مشاكل تشفير مماثلة.

يمكن رؤية هذه المشكلة في برنامج جداول البيانات Microsoft Excel اعتبارًا من عام 2023، والذي يخزن التواريخ كعدد الأيام منذ 31 ديسمبر 1899 (اليوم الأول هو 1 يناير 1900) مع يوم كبيس وهمي في عام 1900 إذا كنت تستخدم نظام التاريخ الافتراضي لعام 1900. بدلاً من ذلك، إذا كنت تستخدم نظام التاريخ لعام 1904، يتم تخزين التاريخ كعدد الأيام منذ 1 يناير 1904 (اليوم الأول هو 2 يناير 1904)، ولا توجد مشكلة سنة كبيسة. أقصى تاريخ مدعوم للحساب هو 31 ديسمبر 9999. ^{[73] [74]}

في أنظمة تشغيل Microsoft WindowsFILETIME ، يخزن الهيكل عدد الفواصل الزمنية التي تبلغ 100 نانوثانية، والمعروفة باسم "النقرات"، منذ 00:00:00.0000000 UTC في 1 يناير 1601 كعدد صحيح موقّع مكون من 64 بت. ستتجاوز هذه القيمة أقصى قيمة ممكنة لها في 14 سبتمبر 30828 عند 02:48:05.4775808 UTC، وبعد ذلك لن يقبل Windows التواريخ التي تتجاوز هذا اليوم وسيعرض أخطاء "وقت النظام غير صالح" في NTFS. ^[75]

ستؤثر مشكلة مماثلة على DateTimeالبنية في لغة البرمجة C# ، والتي تخزن أيضًا دقات مدتها 100 نانوثانية من الساعة 00:00:00 بالتوقيت العالمي المنسق، لكنها تبدأ من 1 يناير 1 م في التقويم الغريغوري . ^[76] ستتجاوز هذه القيمة عام 29228 م في نفس اليوم والوقت مثل Windows FILETIME. ^[77]

قد تواجه البرامج التي تعالج السنوات كقيم مكونة من 16 بت مشاكل في التعامل مع العام 32768 أو 65536، اعتمادًا على ما إذا كانت القيمة تُعامل كعدد صحيح موقّع أو غير موقّع.

بالنسبة لمشكلة عام 32768 ، يمكن تفسير السنوات التي تلي عام 32767 على أنها أرقام سلبية، تبدأ بـ −32768. ^[78] من المرجح أن تظهر مشكلة عام 65536 من خلال ظهور عام 65536 على أنه عام 0. ^[79]

تخزن أرشيفات المكتبات الثابتة التي تم إنشاؤها بواسطة arأمر يونكس الطوابع الزمنية كسلسلة ASCII تحتوي على عدد عشري من الثواني بعد عصر يونكس (1 يناير 1970، 00:00:00 UTC)، مع حد أقصى يبلغ 12 حرفًا ASCII. سيتم ترحيل هذه القيمة في الساعة 01:46:40 UTC في 27 سبتمبر 33658. [ ^{بحاجة لمصدر ]}

سيكون عام 100000 هو أول عام ميلادي مكون من ستة أرقام.

تخزن واجهة برمجة تطبيقات Date في JavaScript التواريخ على هيئة عدد من المللي ثانية منذ 1 يناير 1970. يتراوح نطاق التواريخ بين ±100,000,000 يوم من بداية العصر، مما يعني أن البرامج المكتوبة بلغة JavaScript باستخدام واجهة برمجة تطبيقات Date لا يمكنها تخزين التواريخ بعد 13 سبتمبر 275,760 م. ^[80]

من الناحية النظرية، ستتمكن الأنظمة التي تخزن وقت يونكس بالثواني باستخدام أعداد صحيحة موقعة مكونة من 64 بت من تمثيل التواريخ والأوقات حتى الساعة 15:30:08 بتوقيت UTC يوم الأحد 4 ديسمبر عام 292,277,026,596 ميلادي. ^{[81] [82]} هذا العام بعيد جدًا في المستقبل (بعيدًا جدًا عن العمر المتوقع للأرض والشمس والبشرية وحتى بعض التوقعات حول عمر الكون ) لدرجة أنه يُشار إليه بشكل أساسي كمسألة ذات أهمية نظرية أو نكتة أو إشارة إلى أن الإصدارات السابقة مثل مشكلة عام 2038 لا يمكن "حلها" حقًا إلى الأبد.

في أنظمة التشغيل Microsoft Windows 7 وWindows Server 2003 وWindows Server 2008 وWindows Vista، تم تخزين معلومات بدء اتصال TCP في أجزاء من المائة من الثانية، باستخدام عدد صحيح غير موقّع مكون من 32 بت، مما تسبب في فشل اتصالات TCP بعد 497 يومًا. ^[83]

واجهت أنظمة التشغيل Microsoft Windows 95 وWindows 98 مشكلة تتعلق بمرور ^2.32 ميلي ثانية في برنامج تشغيل الجهاز الظاهري (VTDAPI.VXD)، مما تسبب في تعليق الأنظمة بعد 49.7 يومًا. ^[84]

كان لدى .NET حتى الإصدار 6.0 خطأ تسبب في فشل تسلق مجموعة الخيوط بشكل دوري بعد 49.7 يومًا بسبب حدوث تجاوز فيض أثناء التعامل مع المللي ثانية منذ بدء التشغيل. ^[85]

واجهت طائرة بوينج 787 مشكلتين على الأقل في البرامج تتعلقان بتخزين الوقت. ففي عام 2015، تم الإبلاغ عن خطأ حيث تم تخزين الوقت في مئات من الثانية، باستخدام عدد صحيح مكون من 32 بت، وكانت الأنظمة تتعطل بعد 248 يومًا. [ 86 ^]

في عام 2020، أصدرت إدارة الطيران الفيدرالية توجيهًا بشأن صلاحية الطيران يتطلب من مشغلي 787 إيقاف تشغيل طائراتهم تمامًا قبل الوصول إلى 51 يومًا من التشغيل، وإلا فستبدأ الأنظمة في عرض بيانات مضللة. ^[87]

توفر منصة Arduino وقتًا نسبيًا عبر دالة millis(). تعيد هذه الدالة قيمة غير موقعة مكونة من 32 بتًا لـ "مللي ثانية منذ بدء التشغيل"، والتي ستتدحرج كل 49.71 يومًا. بشكل افتراضي، هذا هو مصدر التوقيت الوحيد المتاح في المنصة وتحتاج البرامج إلى توخي عناية خاصة للتعامل مع عمليات التدحرج. ^[88] داخليًا، تعتمد millis() على عد مقاطعات المؤقت. تعمل أوضاع توفير الطاقة المحددة على تعطيل المقاطعات وبالتالي منع العداد من التقدم أثناء السكون. ^[89]

بالنسبة للسنوات التاريخية أيضًا، قد تكون هناك مشكلات عند التعامل مع الأحداث التاريخية، على سبيل المثال:

• مشكلة السنة صفر
• مشكلة سنة 1000
• مشكلة سنة 1582
• مشكلة سنة 1900

• خطأ في البرنامج
• هايزنباغ
• مؤسسة لونج ناو