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

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

في 5  يناير 1975، حدث خطأ برمجي يُعرف باسم "DATE75"، حيث تجاوز حقل التواريخ ذو الـ 12 بت المُستخدم في نظام التشغيل TOPS-10 لأجهزة الكمبيوتر DEC PDP-10 سعة التخزين المخصصة له. وقد حُسبت قيمة الحقل بأخذ عدد السنوات منذ 1  يناير 1964، وضرب الناتج في 12، ثم إضافة عدد الأشهر منذ يناير، وضرب الناتج في 31، ثم إضافة عدد الأيام منذ بداية الشهر. القيمة القصوى التي يمكن تمثيلها باستخدام عدد صحيح غير مُوقّع ذي 12 بت هي 2 ^{^12} - 1 = 4095 ، والقيمة 4095 تُمثل تاريخ 4  يناير 1975.${\displaystyle (((11{\text{ years since 1964}})\times 12)+0{\text{ months since January}})\times 31)+3{\text{ days since start of the month}}=4095}$

لذا، يُعدّ 4  يناير 1975 آخر تاريخ قابل للترميز. وقد أدّى تصحيح "DATE-75" إلى تأجيل آخر تاريخ قابل للترميز إلى 1  فبراير 2052، مما جعل تاريخ الفائض 2  فبراير 2052، وذلك باستخدام 3 بتات إضافية من حقول أخرى في بيانات تعريف نظام الملفات . إلا أن هذا الأمر تسبب أحيانًا في مشاكل مع البرامج التي تستخدم هذه البتات لأغراضها الخاصة. ربما دعمت بعض البرامج استخدام بت إضافي واحد للتاريخ، لكنها واجهت مشاكل مع البتات الإضافية، مما قد يكون أدى إلى ظهور بعض الأخطاء في 9 يناير 1986. ^{[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]} 

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

وقد تم إدراك ذلك عند تطوير نظام التشغيل COS-310 ، وتم تسجيل التواريخ بطريقة مختلفة. ^{[ 7 ]}

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

في نظام التشغيل Domain/OS الخاص بشركة Apollo Computer ، كان يتم تخزين الوقت المطلق كعدد صحيح ذي إشارة مكون من 48 بت يمثل عدد وحدات 4 ميكروثانية منذ 1 يناير 1980. وقد تجاوزت هذه القيمة الحد المسموح به في 2 نوفمبر 1997، مما جعل الأنظمة غير المحدثة غير قابلة للاستخدام. ^{[ 5 ] [ 10 ]}  

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

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

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

واجهت بعض الأنظمة مشاكل بمجرد حلول عام 2010. وقد أطلق عليها البعض في وسائل الإعلام اسم مشكلة "Y2K+10" أو "Y2.01k". ^{[ 15 ]}

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

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

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

وتشمل الأنظمة الأخرى المتأثرة أجهزة نقاط البيع الإلكترونية ، ^{[ 19 ]} وجهاز بلاي ستيشن 3 (باستثناء طراز Slim). ^{[ 20 ]}

تعامل جهاز بلاي ستيشن 3 من سوني بشكل خاطئ مع عام 2010 باعتباره سنة كبيسة  ، لذا ظهر تاريخ 29 فبراير 2010 غير الموجود في 1  مارس 2010، مما تسبب في خطأ برمجي . ^{[ 5 ] [ 21 ]}

تستخدم تايوان رسميًا تقويم مينغوو ، الذي يعتبر السنة الميلادية 1912 هي السنة الأولى لها. وبالتالي، فإن السنة الميلادية 2011 هي السنة المئوية لتايوان، وهي أول سنة لها تتكون من ثلاثة أرقام. ^{[ 5 ] [ 22 ]} وهذا ما يجعل السنة تبدو وكأنها 1911 (السنة 0) عند استخدام تمثيلات مكونة من رقمين.

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

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

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

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

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

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

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

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

لم تتمكن أجهزة قراءة بطاقات الدفع في محطات الوقود في نيوزيلندا من التعامل مع السنة الكبيسة، وبالتالي لم تتمكن من صرف البنزين بشكل صحيح. ^{[ 41 ]}

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

في ديسمبر 2024، تم اكتشاف خلل برمجي عمره 30 عامًا في جميع إصدارات HCL Notes . عند تشغيل الخادم في 13  ديسمبر 2024 أو بعده، كان يحدث تجاوز في سعة التخزين، مما يمنع موجه البريد من تحميل إعداداته، وبالتالي لا يتم تسليم أي بريد. تم إصدار تصحيحات في اليوم التالي لجميع الإصدارات المدعومة. ^{[ 45 ]}

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

في إسبانيا، توقفت جميع قطارات تالغو من فئة أفريل عن العمل في 1  يناير 2025 بسبب خلل في معالجة التاريخ في وحدة شحن البطارية، مما تسبب في تأخيرات وإلغاءات حيث تم نقل الركاب إلى قطارات أخرى. ^{[ 47 ] [ 48 ]} تم تطبيق إصلاح في اليوم التالي، مما أدى إلى استعادة الخدمة المنتظمة. ^{[ 49 ]}

تسبب خطأ برمجي في dateالأمر من برنامج GNU Core Utilitiesuutils ، وهو نسخة مُعاد كتابتها بلغة Rust ، في توقف التحديثات التلقائية في نظام Ubuntu 25.10 عن العمل. ^{[ 50 ] [ 51 ]}

لا يمكن تغيير تاريخ النظام على جهاز Xbox 360  إلا حتى الساعة 23:59 من يوم 31 ديسمبر 2025. وسيستمر النظام في التقدم حتى عام 2026 وما بعده عبر اتصال Xbox Live ؛ ^{[ 52 ]} ومع ذلك، لا يمكن للمستخدمين تغيير تاريخ النظام بعد هذه النقطة بسبب قيود برمجية في لوحة تحكم Microsoft . ^{[ 53 ]}

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

خلال أواخر سبعينيات القرن العشرين، ابتكرت شركة وورلد كمبيوتر كوربوريشن (المتخصصة في تطبيقات الاتحادات الائتمانية) في أنظمة داتا جنرال نوفا وإكليبس تنسيقًا للتاريخ يتضمن حقلًا من 16 بت، حيث استُخدمت سبعة بتات للسنة، وأربعة بتات للشهر، وخمسة بتات لليوم. وقد أتاح هذا التنسيق إمكانية مقارنة التواريخ مباشرةً باستخدام الدوال غير الموقعة. ولا تزال بعض الأنظمة، بما في ذلك نظام HP 3000 ، تستخدم هذا التنسيق، على الرغم من تطوير رقعة تصحيحية من قِبل مستشارين خارجيين. ^{[ 55 ]}

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

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

وتؤثر المشكلة نفسها أيضاً على بعض تطبيقات لغة ليسب. ^{[ 60 ]}

كانت أجهزة ماك من آبل، حتى نظام macOS X Snow Leopard، تخزن الوقت في ساعات الوقت الحقيقي (RTCs) وأنظمة ملفات HFS كعدد غير مُوقّع من 32 بت للثواني منذ الساعة 00:00:00 في 1  يناير 1904. بعد الساعة 06:28:15 في 6  فبراير 2040 (أي بعد ²³² - 1 ثانية من بداية الحقبة)، سيعود الوقت إلى عام 1904؛ ^{[ 5 ] [ 63 ]} علاوة على ذلك، يتأثر نظام HFS+ ، الذي كان نظام الملفات الافتراضي لمعظم أجهزة آبل، بهذه المشكلة أيضًا. نظام ملفات آبل ، الذي يحل محل HFS وHFS+، يحل هذه المشكلة.

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

في 18 سبتمبر 2042، سيتم تغيير  توقيت الساعة اليومية (TODC) في سلسلة IBM System/370 من أجهزة IBM الرئيسية وخلفائها، بما في ذلك سلسلة IBM Z الحالية. ^{[ 5 ] [ 66 ]}

كانت أجهزة TODC القديمة تُنفذ كعدّ 64 بت بوحدات 2-12 ^{ميكروثانية} (0.244  نانوثانية)، وكان أساسها القياسي هو 1  يناير 1900 بالتوقيت العالمي . في يوليو 1999، أُعلن عن ساعة TODC الموسعة، والتي مددت الساعة إلى اليمين (أي أن البتات الموسعة أقل أهمية من البتات الأصلية). تعتمد الدقة الفعلية على الطراز، لكن التنسيق ثابت، وبالتالي سيعود إلى وضعه الأصلي بعد 252 ^{ميكروثانية} . ^{[ 66 ]}

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

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

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

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

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

تقوم العديد من أنظمة IBM PC و DOS بتخزين السنة داخليًا كقيمة مكونة من رقمين منذ عام 1980، مثل العديد من ساعات الوقت الحقيقي، وستتغير هذه القيم بعد 31  ديسمبر 2079.

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

وبالمثل، فإن أجهزة نينتندو دي إس، وجيم كيوب، وسوني بلاي ستيشن 4 لا تسمح للمستخدمين إلا بتعيين التواريخ حتى عام 2099. في حالة نينتندو دي إس، لن يقوم النظام بتقديم الوقت إلى ما بعد 31  ديسمبر 2099، بينما سيستمر جيم كيوب وبلاي ستيشن 4 في التقديم إلى عام 2100 وما بعده، على الرغم من أن مستخدمي هذه الأجهزة لا يمكنهم إدخال التاريخ والوقت يدويًا في تلك الفترة البعيدة.

تستخدم العديد من تنسيقات الملفات وبروتوكولات الاتصالات وواجهات التطبيقات الحالية صيغةً معدلةً من تنسيق تاريخ يونكسtime_t ، حيث تُخزَّن عدد الثواني منذ بداية حقبة يونكس (منتصف الليل بالتوقيت العالمي المنسق، 1  يناير 1970) كعدد صحيح ثنائي غير مُوقَّع من 32 بت. ستُعاد هذه القيمة إلى وضعها الافتراضي في 7  فبراير 2106 الساعة 06:28:16  بالتوقيت العالمي المنسق. أي أن عدد الثواني منذ 1  يناير 1970 في هذا الوقت مُعبَّر FFFFFFFFعنه بالنظام الست عشري. ^{[ 5 ]}

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

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

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

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

يخزن نظام التشغيل RISC OS التواريخ بوحدات السنتي ثانية (أجزاء من مئة من الثانية) منذ 1  يناير 1900 في خمسة بايتات (40  بت). تُستخدم هذه الطوابع الزمنية داخليًا وتُعرض في بيانات تعريف الملفات (عناوين التحميل والتنفيذ). ^{[ 70 ]} ستتجاوز هذه القيمة الحد الأقصى في 3  يونيو 2248 الساعة 06:57:57.75  بالتوقيت العالمي المنسق. ^{[ 5 ]}

تستخدم بعض أنظمة ضبط الوقت عالية الدقة عددًا صحيحًا مُوَقَّعًا من 64 بت لحساب النانوثانية منذ 1 يناير 1970 ، والذي سيتجاوز الحد الأقصى في 11 أبريل 2262 الساعة 23:47:16  بالتوقيت العالمي المنسق. تُعد واجهة برمجة التطبيقات (API) للغة البرمجة GoUnixNano مثالًا على ذلك. ^{[ 71 ]} تشمل الأمثلة الأخرى كائن Timestamp في مكتبة pandas في بايثون ، ^{[ 72 ]} والفئة chronoفي لغة C++ عند ضبطها على دقة النانوثانية، ^{[ 73 ]} ومؤقتات QEMU . ^{[ 74 ]}

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

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

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

في القرن التاسع عشر، اقترح السير جون هيرشل تعديلًا على التقويم الغريغوري بإضافة 969 يومًا كبيسًا كل 4000 عام، بدلًا من 970 يومًا كبيسًا التي كان يضيفها التقويم الغريغوري خلال الفترة نفسها. ^{[ 77 ]} من شأن هذا التعديل أن يُقلل متوسط ​​السنة إلى 365.24225 يومًا. وبموجب اقتراح هيرشل، أصبحت السنة 4000، ومضاعفاتها، سنةً عادية بدلًا من سنة كبيسة. ورغم أن هذا التعديل قد طُرح مرارًا منذ ذلك الحين، إلا أنه لم يُعتمد رسميًا قط. ^{[ 78 ]}

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

يستخدم برنامج مايكروسوفت أوتلوك التاريخ  1 يناير 4501 كقيمة افتراضية لـ "لا شيء" أو "فارغ". ^{[ 5 ] [ 81 ] [ 82 ]}

سيكون عام 10000 أول عام ميلادي بخمسة أرقام. وستواجه الأنظمة التي لا تسمح إلا بأربعة أرقام كحد أقصى للسنة مشاكل في التعامل مع جميع السنوات اللاحقة التي هي قوى العدد 10، بالإضافة إلى التواريخ التي تسبق الألفية العاشرة قبل الميلاد .

يستخدم الإصدار السابع من UUID طابعًا زمنيًا مكونًا من 48 بت، والذي سيتجاوز الحد الأقصى في عام 10889 ميلادي. ^{[ 86 ]}

في لغة البرمجة C# ، أو أي لغة تستخدم .NET ، DateTimeيقوم الهيكل بتخزين الطوابع الزمنية المطلقة كعدد أجزاء من عشرة ميكروثانية (10 ⁻⁷  ثانية، والمعروفة باسم "النبضات" ^{[ 87 ]} ) منذ منتصف الليل (00:00:00.0000000  UTC) في 1  يناير 1  ميلادي في التقويم الغريغوري الاستباقي ، ^{[ 88 ]} والذي سيتجاوز عدد صحيح موقع 64 بت في 14  سبتمبر 29228 في الساعة 02:48:05.4775808  UTC. ^{[ 5 ] [ 89 ]} تتميز هياكل ضبط الوقت في العديد من تطبيقات وخدمات مايكروسوفت بدقة تصل إلى 100 نانوثانية، مثل نوع بيانات Power Automate ، ^{[ 90 ]} والاستعلام في Azure Cosmos DB ، ^{[ 91 ]} والمعامل في أوامر Windows PowerShell المختلفة ، ^{[ 92 ]} وستواجه جميعها مشكلات مماثلة. مع ذلك، تُعتبر التواريخ التي تتجاوز 31 ديسمبر 9999 الساعة 23:59:59.9999999 بالتوقيت العالمي المنسق "غير مدعومة"، وستُظهر عمليات الوقت أخطاءً عمدًا عندما تُؤدي الحسابات إلى تواريخ لاحقة لـ 9999. ^{[ 93 ]}TIMEGETCURRENTTICKSTimeSpan  

في أنظمة تشغيل ويندوزFILETIME ، يخزن هذا الهيكل عدد أجزاء الميكروثانية العشرية منذ منتصف الليل (00:00:00.0000000 بالتوقيت العالمي المنسق) في 1 يناير 1601 وفقًا للتقويم الغريغوري المتقدم، كعدد صحيح ذي إشارة 64 بت. ستتجاوز هذه القيمة الحد الأقصى في 14  سبتمبر 30828 الساعة 02:48:05  بالتوقيت العالمي المنسق، وبعدها لن يتمكن ويندوز من قبول التواريخ وسيعرض أخطاء "وقت النظام غير صالح". ^{[ 5 ] [ 94 ]}

وبالمثل، تُرجع GETCURRENTTICKSSTATICالأوامر في Cosmos DB عدد النبضات التي تبلغ مدتها 100 نانوثانية منذ بداية حقبة يونكس في منتصف الليل (00:00:00.0000000  UTC) في 1  يناير 1970، ^{[ 95 ]} والتي ستنتهي في 14  سبتمبر 31197 في الساعة 02:48:05. ^{[ 96 ]}

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

في الأنظمة التي تستخدم أعدادًا صحيحة ذات 16 بت مُوَقَّعة، قد تُفسَّر السنوات التي تلي 32767 على أنها أعداد سالبة، ^{[ 5 ] [ 97 ]} بدءًا من -32768 والتي قد تُعرض على أنها 32768 قبل الميلاد . أما في الأنظمة التي تستخدم أعدادًا صحيحة ذات 16 بت غير مُوَقَّعة، فمن المرجح أن تظهر المشكلة من خلال ظهور السنة 65536 على أنها السنة 0، ^{[ 5 ] [ 98 ]} أو عودة السنة 65537 إلى السنة 1. 

تخزن أرشيفات المكتبات الثابتة التي ينشئها arأمر يونكس الطوابع الزمنية كسلسلة ASCII تحتوي على عدد عشري من الثواني بعد بداية حقبة يونكس ، بحد أقصى 12 حرفًا من ASCII. ستُعاد هذه القيمة في الساعة 01:46:40  بالتوقيت العالمي المنسق في 27  سبتمبر 33658، أي بعد تريليون ثانية من بداية حقبة يونكس. ^{[ 5 ]}

سيكون عام 100,000 أول عام ميلادي بستة أرقام.

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

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

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

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

• خطأ هايزنبج – خطأ برمجي يبدو أنه يتغير عند تصحيح الأخطاء 
• مؤسسة لونغ ناو - منظمة أمريكية غير ربحية