ما هو الطابع الزمني لـ Unix؟

الطابع الزمني لـ Unix هو رقم واحد: عدد الثواني التي انقضت منذ حقبة Unix، المُعرَّفة على أنها 00:00:00 UTC في 1 يناير 1970. هذا كل شيء. لا منطقة زمنية، ولا سلسلة تاريخ، ولا أسماء أشهر — مجرد عدد صحيح يتزايد بمقدار واحد كل ثانية.

لأن الحقبة ثابتة وعالمية، فإن طابعًا زمنيًا مثل 1700000000 يعني نفس اللحظة بالضبط في كل مكان على الأرض. سيتفق خادم في طوكيو وجهاز محمول في شيكاغو على أنه يشير إلى 14 نوفمبر 2023 الساعة 22:13:20 UTC. يختلف العرض المحلي حسب المنطقة الزمنية، لكن الرقم الأساسي لا يختلف أبدًا.

تبسيط متعمد واحد: وقت Unix يتجاهل الثواني الكبيسة. يفترض أن كل يوم يبلغ طوله 86,400 ثانية بالضبط، وهذا ليس صحيحًا تمامًا من الناحية الفلكية لكنه يحافظ على نظافة العمليات الحسابية. المزيد عن ذلك أدناه.

لماذا يحبها المهندسون

الطوابع الزمنية موجودة في كل مكان في البرمجيات — أوقات تعديل الملفات، سجلات قواعد البيانات، استجابات API، حقول انتهاء صلاحية JWT، سطور السجلات — ولسبب وجيه:

• إنها قيمة واحدة. عدد صحيح واحد يخزن تاريخًا ووقتًا كاملين. لا تحليل، لا غموض حول MM/DD مقابل DD/MM.
• إنها غير مرتبطة بالمنطقة الزمنية. الرقم دائمًا UTC. تقوم بالتحويل إلى الوقت المحلي فقط عندما تعرضه لإنسان.
• يمكن مقارنتها وفرزها بسهولة. أي حدث حدث أولاً؟ العدد الصحيح الأصغر. المدة بين حدثين؟ اطرحهما؛ الإجابة بالثواني.
• تخزين مضغوط. عدد صحيح واحد بحجم 4 أو 8 بايت مقابل سلسلة منسقة.

لهذا السبب تتحدث الكثير من البنية التحتية بثواني الحقبة تحت الغطاء، حتى عندما تظهر لك الواجهة 2026-07-23 بشكل ودود. إذا كنت تريد الانتقال بين التمثيلين، فإن محول الطابع الزمني يونكس يقوم بالترجمة في كلا الاتجاهين.

قراءة طابع زمني: مثال عملي

خذ الطابع الزمني 1000000000 — وهو مشهور، لأنه تجاوز الحد على الهواء مباشرة بين عشاق Unix.

لقراءته يدويًا، تقسم الثواني إلى وحدات أكبر. تقريبًا، 1,000,000,000 ثانية تساوي حوالي 31.7 سنة (السنة ~31,556,952 ثانية). أضف ذلك إلى حقبة 1970 وستصل إلى 2001. اللحظة الدقيقة هي 09 سبتمبر 2001، 01:46:40 UTC.

نادرًا ما تقوم بهذه الحسابات يدويًا — كل لغة تحتوي على دالة مدمجة. في بايثون:

```python from datetime import datetime, timezone datetime.fromtimestamp(1000000000, tz=timezone.utc)

2001-09-09 01:46:40+00:00

```

النقطة الرئيسية: التحويل دائمًا مرتبط بـ UTC. تقوم الدالة بتحويل عدد الثواني الخام إلى تاريخ تقويمي بالتقدم للأمام من الحقبة. إذا كنت تريد الوقت المحلي بدلاً من ذلك، تقوم بتطبيق إزاحة المنطقة الزمنية بعد تحويل UTC — الطابع الزمني نفسه لا يحمل أي معلومات عن المنطقة.

مشكلة عام 2038

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

لعقود، كان النوع القياسي في C المستخدم لتخزين وقت Unix، time_t، عادةً عددًا صحيحًا موقّعًا 32 بت. يمكن للعدد الصحيح الموقّع 32 بت تمثيل قيم من −2,147,483,648 حتى 2,147,483,647. هذا الحد الأعلى هو المشكلة.

عند عد الثواني من حقبة 1970، يتم الوصول إلى القيمة 2,147,483,647 في 03:14:07 UTC في 19 يناير 2038. بعد ثانية واحدة، يحتاج العداد إلى أن يصبح 2,147,483,648 — لكن هذا الرقم لا يتسع في عدد صحيح موقّع 32 بت. بدلاً من الاستمرار في الصعود، تفيض البتات وتلتف إلى القيمة الأكثر سالبية، −2,147,483,648.

يتم تفسير الطابع الزمني السالب على أنه وقت قبل الحقبة. لذا فإن الساعة لا تتوقف فقط — بل تقفز إلى الوراء إلى 13 ديسمبر 1901. أي نظام وثق في time_t 32 بت الخاص به يعتقد فجأة أنه في أوائل القرن العشرين.

يُطلق على هذا غالبًا خلل Y2K38 أو خلل الألفية لـ Unix، وهو من الناحية الهيكلية نفس النوع من الفيضان ذي العرض الثابت الذي تسبب في ذعر عام 2000 — لكنه أبعد زمنيًا وجذوره في حدود الأعداد الصحيحة الثنائية بدلاً من السنوات المكونة من رقمين.

أين يظهر تأثيره فعليًا

تم إصلاح أجهزة الكمبيوتر المكتبية والخوادم الحديثة 64 بت إلى حد كبير منذ سنوات. يتركز الخطر في الأماكن التي يصعب تحديثها:

• الأنظمة المدمجة والصناعية. أجهزة التوجيه، وحدات التحكم، الأجهزة الطبية، وحدات التحكم الإلكترونية في السيارات، وأجهزة إنترنت الأشياء التي تم شحنها مع time_t 32 بت وقد تعمل دون تغيير لأكثر من 20 عامًا. العديد من الأجهزة المنشورة اليوم ستظل قيد الخدمة في 2038.
• كود C القديم. التطبيقات التي تم تجميعها مقابل تعريف time_t قديم، خاصة حيث تسلل النوع إلى تنسيقات التخزين على القرص أو بروتوكولات الشبكة.
• قواعد البيانات وأنظمة الملفات القديمة. تنسيقات التخزين التي ضغطت الطوابع الزمنية في حقول 32 بت. بعض الأنظمة القديمة تظهر بالفعل أعراضًا عند التعامل مع تواريخ بعيدة في المستقبل — فكر في رهن عقاري لمدة 20 عامًا أو شهادة انتهاء صلاحية تتجاوز 2038.

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

الإصلاح: وقت 64 بت

العلاج بسيط من حيث المبدأ — توسيع time_t إلى 64 بت. يمكن للعدد الصحيح الموقّع 64 بت عد الثواني إلى ما هو أبعد بكثير من أي أفق عملي: نقطة الفيضان تقع تقريبًا 292 مليار سنة في المستقبل، مريحة بعد العمر المتوقع للشمس.

معظم أنظمة التشغيل الحالية قامت بالفعل بهذه الخطوة. لينكس 64 بت يستخدم time_t 64 بت؛ حتى لينكس 32 بت حصل على دعم الوقت 64 بت في النواة و glibc في السنوات الأخيرة. الجزء الصعب ليس الإصلاح نفسه — بل إيجاد وإعادة بناء كل قطعة برمجيات ثابتة، كل تنسيق تخزين، وكل ملف ثنائي تابع لجهة خارجية لا يزال يفترض 32 بت. هذا العمل التدقيقي هو مشروع 2038 الحقيقي.

كيف تتناسب الثواني الكبيسة

الوقت الفلكي والوقت الذري ينحرفان قليلاً عن بعضهما، لذا تقوم UTC الرسمية أحيانًا بإدراج ثانية كبيسة للحفاظ على الساعات متوافقة مع دوران الأرض. وقت Unix، حسب التصميم، يتظاهر بأن هذه غير موجودة — فهو يثبت 86,400 ثانية في اليوم.

عند حدوث ثانية كبيسة، تقوم الأنظمة عادةً "بتمديدها" — نشر الثانية الإضافية عبر نافذة (شاع جوجل تمديدًا لمدة 24 ساعة) بحيث لا تضطر أي ساعة أبدًا إلى إظهار 23:59:60 المستحيل. النتيجة: تبقى الطوابع الزمنية لـ Unix سلسة ورتيبة، على حساب كونها متأخرة بجزء صغير من الثانية عن UTC الصارمة أثناء التمديد. بالنسبة لجميع البرمجيات تقريبًا، هذه هي المقايضة التي تريدها بالضبط. فيضان 2038 هو مشكلة عرض عدد صحيح؛ الثواني الكبيسة هي خصوصية تعريف منفصلة وأصغر بكثير — لا تخلط بينهما.

النقاط الرئيسية

• الطابع الزمني لـ Unix هو ثوانٍ منذ 00:00:00 UTC في 1 يناير 1970، مع تجاهل الثواني الكبيسة.
• إنه عدد صحيح واحد غير مرتبط بالمنطقة الزمنية — سهل التخزين والمقارنة والفرز.
• التحويل دائمًا نسبي إلى UTC؛ يتم تطبيق الوقت المحلي بعد ذلك.
• العدد الصحيح الموقّع 32 بت time_t يفيض عند 03:14:07 UTC في 19 يناير 2038، ملتفًا إلى قيمة سالبة ويقفز إلى 1901.
• الإصلاح هو time_t 64 بت؛ الجهد هو تدقيق الأنظمة المدمجة والقديمة.

هل تريد رؤيته عمليًا؟ الصق أي قيمة حقبة في محول الطابع الزمني يونكس لقراءتها كتاريخ بشري — أو اذهب في الاتجاه الآخر وحوّل تاريخًا إلى طابعه الزمني.

الأسئلة الشائعة

هل الطابع الزمني لـ Unix بالثواني أم بالمللي ثانية؟

وقت Unix الكلاسيكي يكون بالثواني. ومع ذلك، تستخدم JavaScript والعديد من واجهات برمجة تطبيقات الويب المللي ثانية منذ الحقبة، لذا فإن قيمة مثل 1700000000000 أكبر بـ 1,000 مرة. علامة سريعة: الطابع الزمني بالثواني لتاريخ حديث يحتوي على 10 أرقام؛ بينما يحتوي بالمللي ثانية على 13. عند الشك، تحقق من المقدار قبل التحويل.

هل ستتسبب مشكلة عام 2038 في تعطل هاتفي أو جهازي المحمول؟

بالتأكيد لا تقريبًا. تستخدم أنظمة التشغيل الحديثة 64 بت بالفعل time_t 64 بت، مما يدفع الفيضان إلى مليارات السنين. التعرض الحقيقي هو في الأجهزة المدمجة طويلة العمر والبرامج القديمة التي لا تزال تعتمد على الوقت 32 بت وقد لا يتم تحديثها قبل 2038.

هل يمكن أن يكون الطابع الزمني لـ Unix سالبًا؟

نعم. القيم السالبة تمثل لحظات قبل حقبة 1970 — على سبيل المثال، -1 هو 31 ديسمبر 1969، 23:59:59 UTC. هذا هو بالضبط ما ينتجه فيضان 32 بت في 2038، ولهذا تبدو الساعة وكأنها تقفز إلى 1901.

لماذا يتجاهل وقت Unix الثواني الكبيسة؟

للحفاظ على العمليات الحسابية بسيطة وقابلة للتنبؤ. معاملة كل يوم على أنه 86,400 ثانية بالضبط يعني أن المدد هي مجرد طرح، وتبقى الطوابع الزمنية رتيبة. يتم التعامل مع عدم التطابق الصغير مع UTC الفلكية عن طريق "تمديد" الثانية الكبيسة، وهو ما تفضله جميع التطبيقات تقريبًا على التعامل مع حالة حافة 23:59:60.

كيف أحول طابعًا زمنيًا دون كتابة كود؟

استخدم أداة عبر الإنترنت. تقبل محول الطابع الزمني يونكس قيمة حقبة وتظهر UTC والتاريخ والوقت المحلي المطابقين فورًا، وتحول التواريخ التقويمية أيضًا إلى طوابع زمنية.