ماذا يجب أن نفعل للتحضير 2038?

Question

أود أن أعتقد أن بعض البرامج أنا أكتب اليوم سيتم استخدامها في 30 عاما.ولكن أنا أيضا على علم بأن الكثير من أنها تستند إلى UNIX تقليد تعريض الوقت عدد الثواني منذ عام 1970.

#include <stdio.h>
#include <time.h>
#include <limits.h>

void print(time_t rt) {
    struct tm * t = gmtime(&rt);
    puts(asctime(t));
}

int main() {
    print(0);
    print(time(0));
    print(LONG_MAX);
    print(LONG_MAX+1);
}

نتائج التنفيذ في:

• Thu Jan 1 00:00:00 1970
• Sat Aug 30 18:37:08 2008
• الثلاثاء يناير 19 03:14:07 2038
• Fri Dec 13 20:45:52 1901

وظائف ctime(), gmtime () ، localtime() اتخاذ جميع كحجة قيمة الوقت يمثل الوقت بالثواني منذ عصر (00:00:00 UTC, January 1, 1970;ترى الوقت(3) ).

وأتساءل عما إذا كان هناك أي شيء استباقية في هذا المجال كمبرمج, أو نحن على ثقة من أن جميع أنظمة البرمجيات (ويعرف أيضا باسم أنظمة التشغيل) سوف بعض كيف تكون سحرية ترقية في المستقبل ؟

التحديث يبدو أن الواقع أنظمة 64 بت في مأمن من هذا:

import java.util.*;

class TimeTest {
    public static void main(String[] args) {
        print(0);
        print(System.currentTimeMillis());
        print(Long.MAX_VALUE);
        print(Long.MAX_VALUE + 1);
    }

    static void print(long l) {
        System.out.println(new Date(l));
    }
}

• Wed Dec 31 16:00:00 PST 1969
• Sat Aug 30 12:02:40 PDT 2008
• Sat Aug 16 23:12:55 PST 292278994
• Sun Dec 02 08:47:04 PST 292269055

ولكن ماذا عن العام 292278994?

Answer 1

كنت قد كتبت المحمولة استبدال الوقت.ح (حاليا فقط localtime(), gmtime(), mktime() و timegm()) والذي يستخدم 64 بت الوقت حتى على 32 بت الآلات.المقصود هو أن سقط في ج المشاريع كبديل عن الوقت.ح.يتم استخدامه في بيرل و أنا أنوي أن إصلاح روبي و بايثون 2038 المشاكل مع أنها كذلك.هذا يعطيك آمنة ومجموعة من +/- 292 مليون سنة.

يمكنك العثور على رمز في y2038 المشروع.لا تتردد في الرد على أي أسئلة تعقب المسألة.

كما أن "هذا لن يكون مشكلة لمدة 29 عاما", الإطلاع على هذا قائمة من الأجوبة النموذجية إلى هذا.باختصار, هذه الاشياء تحدث في المستقبل و في بعض الأحيان تحتاج إلى معرفة متى.لدي أيضا عرض المشكلة ما هو الحل و ما هو.

لا ننسى أن العديد من أنظمة الوقت لا تحمل تواريخ قبل عام 1970.حصل قبل عام 1970, في بعض الأحيان كنت بحاجة إلى معرفة متى.

Answer 2

يمكنك تطبيق دائما RFC 2550 و تكون آمنة إلى الأبد؛ -)

فإن الكون متناه في الماضي والمستقبل.العصر الحالي من الكون يقدر [سيبوه] كما بين 10 ** 10 2 * 10 ** 10 سنوات.وفاة الكون يقدر [نايجل] تحدث في 10 ** 11 - سنوات في [دريك] كما تحدث إما في 10 ** 12 سنوات مغلقة الكون (big crunch) أو 10 ** 14 عاما على الكون المفتوح (الموت الحراري للكون).

 

Y10K متوافقة مع برامج اختيار الحد من نطاق التواريخ أنها دعم تلك متسقة مع الحياة المتوقعة من الكون.Y10K متوافقة مع أنظمة يجب أن يقبل Y10K المواعيد من 10 ** 12 سنة في الماضي إلى 10 ** 20 سنة في المستقبل.Y10K متوافقة مع أنظمة ينبغي أن تقبل التمر لمدة 10 ** 29 سنة في الماضي ، في المستقبل.

Answer 3

Visual Studio انتقلت إلى 64 بت تمثيل time_t في Visual Studio 2005 (في حين لا يزال يترك _time32_t من أجل التوافق).

طالما كنت حذرا دائما كتابة التعليمات البرمجية من حيث time_t و لا تفترض أي شيء عن الحجم ثم sysrqb نقاط من أصل المشكلة سيتم حلها عن طريق مترجم.

Answer 4

أعتقد أننا يجب أن تترك علة في.ثم عن 2036 يمكننا البدء في بيع الاستشارات للحصول على مبالغ كبيرة من المال إلى اختبار كل شيء.بعد كل هذا أليس هذا كيف تمكنا بنجاح 1999-2000 التمديد.

أنا أمزح فقط!

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

Answer 5

نظرا عمري, أعتقد أنني يجب أن تدفع الكثير إلى التقاعد ودفع كل ما عندي من الديون ، لذلك شخص آخر يجب أن تناسب البرنامج!

آسف إذا كنت تفكر في "صافي القيمة الحالية" من أي برنامج كنت أكتب اليوم ليس له تأثير البرنامج في عام 2038.و "العائد على الاستثمار" أكثر من بضع سنوات هو المألوف لأي مشروع البرنامج, لذلك يمكنك كسب الكثير من المال لصاحب العمل الخاص بك عن طريق الحصول على البرامج التي يتم شحنها أسرع بدلا من التفكير في ذلك.

المشترك الوحيد استثناء هو البرامج التي تم التنبؤ بها في المستقبل ، 2038 هو بالفعل مشكلة الرهن العقاري اقتباس النظم.

Answer 6

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

Answer 7

ماذا يجب أن نفعل للتحضير 2038?

إخفاء, لأن نهاية العالم قادمة.

ولكن على محمل الجد, أتمنى أن المجمعين (أو الناس الذين يكتبون لهم ، على وجه الدقة) يمكن التعامل مع هذا.لقد حصلت على ما يقرب من 30 عاما.أتمنى أن هذا ما يكفي من الوقت.

في نقطة ما نبدأ التحضير Y10K?أي الشركات المصنعة للأجهزة / مختبرات البحوث نظرت إلى أسهل طريقة للانتقال إلى أي تكنولوجيا جديدة علينا بسبب ذلك ؟

Answer 8

أنا أعمل في وجزءا لا يتجزأ فكرت في ما بعد الحل لدينا هنا.لدينا أنظمة 32 بت و ما نبيع الآن لديه warantee من 30 عاما الأمر الذي يعني أنها سوف تواجه في العام 2038 علة.الترقية في المستقبل ليس حلا.

لحل هذه المشكلة, ونحن مجموعة نواة تاريخ 28 عاما في وقت سابق هذا التاريخ الحالي.انها ليست عشوائية تعويض 28 عاما هو اكسكاتلي الوقت سوف يستغرق أيام الأسبوع إلى المباراة مرة أخرى.مثلا أنا أكتب هذا في يوم الخميس وفي المرة القادمة 7 مارس سيكون يوم الخميس في 28 عاما.

وعلاوة على ذلك ، فإن جميع التطبيقات التي تتفاعل مع التواريخ على أنظمتنا سوف تأخذ تاريخ النظام (time_t) تحويل ذلك إلى العرف time64_t وتطبيق 28 عاما الإزاحة إلى التاريخ الصحيح.

قدمنا العرف مكتبة للتعامل مع هذا.رمز نستخدمه هو أساس الخروج من هذا: https://github.com/android/platform_bionic

وهكذا مع هذا الحل يمكنك شراء نفسك إضافية 28 عاما بسهولة.

Answer 9

قبل 2038, مكتبات وقت يجب أن يكون كل استخدام 64 بت الصحيحه لذا لن يكون في الواقع مشكلة كبيرة (على البرامج التي ليس تماما غير المشرف عليها).

COBOL البرامج قد يكون ممتعا.

Answer 10

منطوق كلمة "ينبغي".

إذا كنت بحاجة إلى ضمان futureproofing ثم يمكنك بناء الخاصة بك التاريخ/الوقت من الدرجة واستخدام ذلك ولكن كنت فقط تفعل ذلك إذا كنت تعتقد أن ما تكتبه على إرث نظام التشغيل'