معالجة y2.036k و y2.038k الحشرات

Question

أنا أعمل حاليًا على مشروع مع شرط يجب أن يعمل برنامجنا حتى عام 2050 على الأقل. واجهنا مؤخرًا مشاكل في التعامل مع "Bug" Y2.036K في بروتوكول NTP وأيضًا علة Y2.038K. في الأساس ، يجب أن يستمر برنامجنا في تجاوز هذه التواريخ مع جميع البيانات المسجلة باستخدام الطوابع الزمنية الصحيحة. بالنظر إلى أنه لا يوجد حاليًا حل لأي من هذه الأخطاء ، يجب استخدام الحل.

من الأهمية بمكان أن يستمر برنامجنا في التشغيل بعد تواريخ هذين الحدثين والسجلات بشكل صحيح. ليس من الأهمية بمكان أن يكون وقت نظام نظام التشغيل صحيحًا. بالنظر إلى أننا نستخدم Java ، يجب أن نكون قادرين على التعامل مع التواريخ بالنسبة إلى الحقبة الأولية لعام 1900 بعد أن تنتهي. ومع ذلك ، فإن Java JVM لن يتم تشغيله إذا تم تعيين وقت النظام قبل Unix Epoch في عام 1970! انها مجرد تعطل.

لإضافة الوقود إلى النار ، يتم توفير خادم NTP بواسطة بائع آخر وليس لدينا أي سيطرة عليه. لذا فإن استخدام بروتوكول آخر أو تعديل الخادم للتعامل مع أي من هذا غير ممكن.

مطلوب حل إبداعي. وغني عن القول ، يجب أن تحدث بعض الفودو العميق. لقد فكرنا في ما يلي:

1. قم بتعديل برنامج عميل NTPD للتعاون بطريقة ما مع خادم NTP وتعويض التوقيت المحلي من تاريخ أكبر من عصر UNIX في عام 1970 بدلاً من عام 1900. وبالتالي السماح لـ JVM بالتشغيل دون التعطل على التهيئة. سيتم التعامل مع جميع الطوابع الزمنية بالنسبة إلى تاريخ الترحيل المختار. (لذلك ، تأكد من نقلنا إلى تاريخ أكبر من عصر UNIX).

2. السماح لـ NTP بتصحيح الوقت للترحيل إلى 1900 عصر وإيجاد إصلاح حتى لا يعطل JVM.

هل تعامل أي شخص آخر مع هذه القضية؟ وأيضًا ، هل هناك أي مشكلات أخرى قد تحدث لم أتوقعها ، مما يجعل أحدهما أو كلاهما غير ممكن على الإطلاق؟

Answer 1

قم بتثبيت برنامجك على Linux 64 بت مع JVM 64 بت. time_t والأصدقاء 64 بت هنا ، اضبط الوقت الماضي في عام 2038 لمعرفة ما إذا كانت الأشياء لا تزال تعمل. إذا كنت جيدًا ، فقم بإلقاء NTP أو ابحث عن GPS أو مصدر آخر يمكن استخدامه على مدار الساعة وضمان أنه لا يواجه 32 بتات ، قم بتعامل البرنامج الخاص بك لقراءة/مزامنة وقت من ذلك.