محوّل طوابع Unix الزمنية
من الطوابع إلى التواريخ والعكس، مع تحديد الوحدة تلقائيًا وذكرها.
اتركه فارغًا لرؤية الوقت الحالي. الرقم المجرّد يُقرأ طابعًا زمنيًا بنظام يونكس.
عدّ الأرقام
الجزء الوحيد الصعب حقاً في قراءة طابع زمني هو معرفة وحدته، ورتبة المقدار تحسم ذلك. ولا لبس في الممارسة، لأن المجالات لا تتداخل عند أي تاريخ يشتغل عليه أحد فعلاً.
| الأرقام | الوحدة | مثال | من أين تأتي |
|---|---|---|---|
| 10 | ثوانٍ | 1787788800 | يونكس وPHP ومعظم الواجهات البرمجية ومطالبات JWT |
| 13 | مللي ثانية | 1787788800000 | جافاسكربت وجافا وكافكا |
| 16 | ميكرو ثانية | 1787788800000000 | دالّة time_ns()/1000 في بايثون، وبنية Postgres الداخلية |
| 19 | نانو ثانية | 1787788800000000000 | Go وInfluxDB وPrometheus |
والخطأ هنا انحرافٌ بمقدار ألف ضعف، فتهبط النتيجة إما في مطلع السبعينيات وإما بعد عشرات الآلاف من السنين. وهو بيّن حين تنظر إليه؛ وغير مرئي البتة حين يكون عموداً واحداً في جدول سجلات، وهناك بالضبط يعضّ.
ماذا يَعُدّ وقت يونكس فعلاً
الثواني منذ الساعة 00:00:00 بتوقيت UTC في 1 يناير 1970، بافتراض أن كل يوم 86٬400 ثانية بالتمام.
وهذا الافتراض خاطئ. فالثواني الكبيسة تُدرَج كل بضع سنين لإبقاء الوقت الذري متوافقاً مع دوران الأرض الذي يتباطأ تدريجياً. ووقت يونكس لا يمثّلها — إذ تكرّر الأنظمة ثانيةً أو تذيبها على مدى يوم كامل كي يبقى العدّ منتظماً.
والنتيجة أن وقت يونكس ليس عدّاً حقيقياً للثواني المنقضية منذ 1970؛ بل ينقصه نحو سبع وعشرين ثانية. وللجدولة والسجلات وانتهاء الصلاحية تلك هي المقايضة الصائبة تماماً، لأن انتظام الحساب أهم من الدقة الفلكية. أما لقياس مدة منقضية حقيقية فاستعمل ساعةً رتيبة بدلاً من ذلك — فساعة الحائط قد تقفز إلى الوراء أيضاً حين يصحّحها بروتوكول NTP.
مشكلة عام 2038
يتّسع العدد الصحيح ذو الإشارة بطول 32 بتاً حتى 2٬147٬483٬647، وهو بوصفه طابعاً زمنياً في يونكس الساعة 03:14:07 بتوقيت UTC في 19 يناير 2038. وبعدها بثانية واحدة يفيض إلى السالب فيصير التاريخ ديسمبر 1901.
وكل ما هو حديث يستخدم 64 بتاً ويكفي نحو 292 مليار سنة. أما غير الحديث فهو البرامج الثابتة المضمّنة، ووحدات التحكم الصناعية، وبعض أنواع أعمدة قواعد البيانات القديمة، وشيفرة C التي ما زالت تفترض time_t بطول 32 بتاً. والأنظمة الأكثر عرضةً للخطر هي التي لا ينظر إليها أحد، وهذا ما جعل مشكلة عام 2000 مكلفة أيضاً.
أي صيغة تستعمل فعلاً
ISO 8601 بتوقيت UTC، لكل ما يعبر حدوداً بين الأنظمة أو يقرؤه إنسان:
2026-08-27T14:30:00Zفهي لا لبس فيها، وتُرتَّب ترتيباً صحيحاً بوصفها نصاً عادياً، وتُقرأ في سجل عند الثانية بعد منتصف الليل. وحرف Z مهم: فبدونه يفترض معظم المحلّلات أن الوقت محلي، فتكون قد اخترعت علّة لا تظهر إلا عند مستخدمين في بلدان أخرى.
وثواني يونكس لا بأس بها داخلياً — فهي ما تستعمله مطالبتا exp وiat في JWT، ومقارنة الأعداد الصحيحة رخيصة. أما الثمن فهو أنها غير مقروءة وأنها تفتح باب الالتباس في الوحدات المذكور أعلاه.
ومما يستحق التجنّب: كل صيغة فيها إزاحة بلا معرّف منطقة زمنية (فـ +01:00 لا يخبرك أذلك بتوقيت BST أم CET، وهذا يهم في التواريخ المستقبلية)، وكل ما يقع في منطقة 03/04/2026، إذ يعني يومين مختلفين تبعاً لأي ضفتي الأطلسي تقرؤه.
تخزين الأحداث المستقبلية
دقيقةٌ توقع الناس. فلاجتماع في التاسعة صباحاً في مارس القادم، يكون تخزين UTC خطأً — إذ لو تغيرت قواعد المناطق الزمنية بين الآن وذاك الحين، والحكومات تغيّرها فعلاً، لتزحزح موعد الاجتماع. فالأحداث المحلية المستقبلية ينبغي تخزينها بوصفها وقتاً محلياً مع معرّف منطقة (Europe/London)، وتحويلها وقت العرض بالقواعد السارية حينئذٍ. أما الأحداث الماضية فعلى العكس: بتوقيت UTC، لأن ما وقع صار ثابتاً.
ذات صلة
مطالبتا exp وiat في JWT بالثواني اليونكسية — وفاكّ ترميز JWT يحوّلهما عنك ويؤشّر على انتهاء الصلاحية. وإن كان مرادك الجدولة لا التحويل، فإن محلّل cron يبيّن متى ينطلق الجدول في المرة القادمة.
أسئلة حول الطوابع الزمنية
هل طابعي الزمني بالثواني أم بالمللي ثانية؟
عُدّ الأرقام. الطابع الزمني الحالي بالثواني عشرة أرقام وسيبقى كذلك حتى نوفمبر 2286؛ وبالمللي ثانية ثلاثة عشر رقماً. وستة عشر رقماً تعني الميكرو ثانية، وتسعة عشر تعني النانو ثانية. والخطأ هنا يزيح الجواب بمقدار ألف ضعف، فتجد نفسك إما بُعيد 1970 وإما في مكان ما من عام 56000 — وهو أمر بيّن إذا نظرت، وغير مرئي داخل سجل. والمحوّل يذكر الوحدة التي افترضها ويتيح لك تغييرها.
ما هي مشكلة عام 2038؟
الأنظمة التي تخزّن وقت يونكس في عدد صحيح ذي إشارة بطول 32 بتاً ستفيض في 19 يناير 2038، فتلتف عائدةً إلى ديسمبر 1901. وكل ما هو حديث يستخدم 64 بتاً وسيصمد نحو 292 مليار سنة. أما ما لن يصمد فهو البرامج الثابتة المضمّنة، وقواعد البيانات الأقدم، وبعض صيغ أنظمة الملفات، وأي شيفرة C ما زالت تستعمل time_t بطول 32 بتاً. وهي مشكلة على شاكلة مشكلة عام 2000، وستُعالَج مثلها في معظمها بهدوء وسلفاً على يد أناس لن تسمع بهم أبداً.
لماذا تتجاهل الطوابع الزمنية الثواني الكبيسة؟
لأن وقت يونكس معرَّف بأنه عدد الثواني منذ الحقبة بافتراض أن كل يوم 86٬400 ثانية بالتمام — وهذا غير صحيح، إذ تُدرَج ثوانٍ كبيسة بين الحين والآخر لإبقاء الساعات متوافقة مع دوران الأرض. وبدل تمثيلها، تكرّر معظم الأنظمة ثانيةً أو تذيبها على مدى فترة كي يبقى العدّ مرتباً. ومعنى ذلك أن وقت يونكس ليس عدّاً حقيقياً للثواني المنقضية، وهذه هي المقايضة الصائبة في كل الأغراض تقريباً.
أي صيغة أستعمل في واجهة برمجية؟
ISO 8601 بتوقيت UTC مع اللاحقة Z، هكذا: 2026-08-27T14:30:00Z. فهي لا لبس فيها، وتُرتَّب ترتيباً صحيحاً بوصفها نصاً، ويقرؤها إنسان يفحص سجلاً في الثانية بعد منتصف الليل. أما ثواني يونكس فلا بأس بها داخلياً وهي ما تستعمله مطالبات JWT، لكنها عصيّة على القراءة وتفتح الباب للخلط بين الثواني والمللي ثانية المذكور أعلاه. والذي يجب تجنّبه هو كل صيغة تحمل إزاحة محلية بلا منطقة زمنية، وكل ما يقع في منطقة الالتباس بين DD/MM وMM/DD.
لماذا يظهر تاريخي بيوم غير المتوقع؟
في الغالب الأعم بسبب حدود المناطق الزمنية. فنص ISO الخالي من المنطقة يفسّره معظم المحلّلات على أنه توقيت محلي، أما المنتهي بحرف Z فهو UTC — لذا فطابع زمني في وقت متأخر من مساء لندن يكون في UTC اليوم التالي أصلاً، وطابع في صباح لوس أنجلوس الباكر يكون فيه اليوم السابق بعد. خزّن وانقل بتوقيت UTC، ولا تحوّل إلا عند العرض.
آخر مراجعة . وجدت شيئاً لم يعد محدَّثاً؟ أخبِرنا.