الخلاصة

  • مثّلت RFC 868 الوقت بعدد ثوانٍ من 32 بت منذ 1 يناير 1900، وأعادته عبر TCP أو UDP على المنفذ 37.
  • ذكر المعيار حدّ عام 2036 منذ البداية. وتُحسب لحظة الالتفاف من عرض الحقل، فيما تكتفي RFC بذكر السنة.
  • انتقل NTP من إرجاع قراءة واحدة إلى مزامنة الساعات ومعالجة العصور الزمنية، وهي مسؤولية أوسع.

قيمة مشتركة للتحقق من الساعة

لم تكن بعض الأنظمة تملك ساعة تقويم، كما كانت ساعات الأجهزة والبشر عرضة للخطأ. اقترحت RFC 868 استطلاع مواقع مستقلة بسرعة ومقارنة النتائج لتأكيد الوقت المحلي أو تصحيحه. وقدمت قيمة يستطيع الحاسوب قراءتها، لا خوارزمية كاملة لمزامنة الساعات.

كان الرقم يحصي الثواني منذ منتصف الليل بتوقيت غرينتش في 1 يناير 1900. يستمع الخادم على المنفذ 37. في TCP يتصل العميل، فيعيد الخادم رقماً ثنائياً من 32 بت ثم يغلق الاتصال. في UDP يرسل العميل مخطط بيانات فارغاً ويتلقى مخططاً يحمل الوقت. وإذا عجز الخادم عن تحديد ساعته، فعليه ألا يختلق قيمة: يرفض اتصال TCP أو يغلقه بلا رقم، أو لا يجيب طلب UDP.

لا تحدد RFC كيفية تعويض تأخير الشبكة أو اختيار مصدر موثوق أو توثيق الرد أو ضبط ساعة العميل. الرقم المقروء آلياً يصلح للمقارنة، لكنه لا يثبت وحده الدقة.

صيغة نصية وخدمة آلية

أرسلت RFC 867 Daytime، الصادرة في الشهر نفسه، التاريخ والوقت كنص ASCII عبر المنفذ 13، لأغراض التنقيح والقياس. أوصت بحروف قابلة للطباعة ولم تفرض تنسيقاً واحداً؛ وأحالت الاستخدامات الآلية إلى RFC 868. الفرق بينهما في طريقة العرض والغرض، وليس دليلاً على تطابق ساعتي الخدمتين أو دقتهما.

يأتي أساس 1900 قبل بداية Unix الشائعة في 1970. وتقدم RFC 868 التحويل بنفسها: منتصف ليل 1 يناير 1970 يساوي القيمة 2,208,988,800. يتيح الأصل الثابت مقارنة أرقام الأنظمة المختلفة ما دامت وحداتها متطابقة.

وللاختصار ثمن معلوم: تقول RFC إن الأساس «سيخدم حتى عام 2036». يصل عدّاد غير موقّع من 32 بت إلى 2³² ثانية في 7 فبراير 2036 عند 06:28:16 بتوقيت غرينتش. هذا التوقيت محسوب من الأصل وعرض الحقل؛ فالوثيقة تذكر السنة فحسب. لا تتسع الثانية التالية في المجال، فيعود العد إلى الصفر. ومن دون سياق إضافي، قد لا يمكن تمييز قيمة بعد الالتفاف عن قيمة من الدورة الأولى.

NTP أخذ على عاتقه مزامنة الساعات

في 1985، وصفت RFC 958 بروتوكول NTP بأنه تطور عن RFC 868 ورسالة ICMP Timestamp، وبديل مناسب لهما. توسعت المهمة إلى مزامنة مجموعة ساعات عبر عملاء وخوادم موزعة، لا مجرد إعادة وقت خادم واحد.

أبقى NTP على أصل 1900، لكنه احتاج إلى تحديد العصر الذي ينتمي إليه الرقم. تشرح RFC 5905 حقل الثواني ذي 32 بت والانتقال من العصر 0 إلى العصر 1 خلال 2036. يحمل الطابع الزمني المرسل كسراً أيضاً، لكن تحديد العصر الأوسع يحتاج إلى سياق. وتبين RFC كيف تساعد معرفة تقريبية بالوقت على تفسير القيم حول الالتفاف.

لا يعني ذلك أن الصيغة القديمة أصبحت بلا نهاية. خففت RFC 868 تبادل الوقت بقيمة ثابتة وأعلنت حدود أساسها. ثم أضاف NTP مزامنة الساعات وتفسير العصور. منذ 1983 كانت الحدود ظاهرة في المعيار: أرسل الإنترنت عدّاً من 1900، لكن الرقم وحده لا يستطيع وصف الفترة التي ينتمي إليها إلى الأبد.

المصادر وحدود الاستنتاج

المصدر الأساسي هو RFC 868, Time Protocol الصادرة في مايو 1983. وتقدم RFC 867 المقارنة النصية، وتوثق RFC 958 أصل NTP الذي يعلنه، وتشرح RFC 5905 التعامل اللاحق مع العصور. ولا تثبت هذه الوثائق عدد الخوادم العاملة أو دقتها أو انتقالاً شاملاً أو عطلاً في 2036.

وتشير RFC 2626 أيضاً إلى التفاف العداد في 2036؛ لكن الدقيقة المحددة التي تطبعها تختلف عن الحساب أعلاه، لذلك نستخدمها هنا لتوثيق التنبيه إلى السنة فقط، لا لتحديد اللحظة (RFC 2626). أسهمت Note 65 لـHeng Lu في صياغة السؤال التحريري حول كيفية استمرار التنفيذ وفق قاعدة مكتوبة؛ وهي منظور تحريري وليست دليلاً تاريخياً (Note 65).