آخر تحديث: 2026-06-28

الطابع الزمني يونيكس (Epoch ⇄ تاريخ)

الطابع الزمني يونيكس عدد صحيح يمثّل عدد الثواني المنقضية منذ اللحظة المرجعية 1970-01-01 00:00:00 بالتوقيت العالمي المنسق (UTC). تعتمده أنظمة الحاسوب معيارًا موحدًا لتخزين اللحظات الزمنية ونقلها بصرف النظر عن المناطق الزمنية أو التقويمات المحلية. يتيح هذا المحوّل التبديل في الاتجاهين: من قيمة epoch رقمية إلى تاريخ UTC مقروء، ومن تاريخ ميلادي إلى قيمته المقابلة في نظام epoch.

أصل حقبة يونيكس ونقطة انطلاقها

اختيار 1970-01-01 00:00:00 UTC نقطةً مرجعية ليس له مسوّغ رياضي خاص؛ بل هو إرث تاريخي من الأيام الأولى لتطوير نظام Unix في مختبرات بيل في أواخر ستينيات القرن العشرين. كان المهندسون في حاجة إلى تاريخ ثابت يُعدّ منه الوقت بصورة متسقة عبر جميع الأجهزة التي يشغّل عليها النظام. انتشرت هذه الاتفاقية إلى معيار POSIX ومنه إلى جميع أنظمة التشغيل ولغات البرمجة المعاصرة تقريبًا.

الطابع الزمني الصفري (0) يعني لحظة الحقبة نفسها. الطابع 86,400 يعني ما بعد الحقبة بيوم كامل (60 ثانية × 60 دقيقة × 24 ساعة). القيم السالبة صحيحة وتمثّل لحظات ما قبل عام 1970، وتدعمها معظم التطبيقات الحديثة للتعبير عن تواريخ تمتد آلاف السنين إلى الوراء.

الثواني والميلي ثانية

معيار Unix الأصلي يقيس الوقت بالثواني الكاملة. ملفات سجلات الخوادم، وسجلات قواعد البيانات، وأدوات صدفة Unix — كلها تستخدم دقة الثواني، مما ينتج قيمًا من عشرة أرقام للتواريخ الواقعة في سنوات الألفين والثلاثينيات.

أدخلت لغة JavaScript نسخة بدقة الميلي ثانية: تُرجع الدالتان Date.now() وDate.getTime() عدد الميلي ثانية منذ الحقبة، فتنتجان قيمًا من ثلاثة عشر رقمًا. كثير من واجهات REST البرمجية وتدفقات الأحداث وقواعد البيانات المرتبطة بـ JavaScript تتبع هذه الاتفاقية.

القاعدة التقريبية: قيمة من عشرة أرقام تكون بالثواني على الأرجح، وقيمة من ثلاثة عشر رقمًا تكون بالميلي ثانية على الأرجح. وللتحويل من الميلي ثانية إلى الثواني يُقسم على 1,000 — وهو ما يجريه هذا المحوّل تلقائيًا عند اختيار وحدة الميلي ثانية.

آلية التحويل

من epoch إلى تاريخ. بمعلومية الطابع الزمني $t$ بالثواني، يُحدَّد التاريخ والوقت بتوقيت UTC وفق:

يُربط عدد الأيام بتاريخ في التقويم الغريغوري المسبق مع مراعاة السنوات الكبيسة، ثم يُحوَّل وقت اليوم إلى ساعات ودقائق وثوانٍ بالقسمة المتتالية مع أخذ باقي القسمة.

من تاريخ إلى epoch. بمعلومية تاريخ ميلادي عند منتصف الليل بتوقيت UTC، تُحسب القيمة بعدّ الأيام من 1970-01-01 وضربها في 86,400. فتاريخ 2024-01-01 مثلًا يبعد 19,723 يومًا عن نقطة البداية، مما يعطي:

$19{,}723 \times 86{,}400 = 1{,}704{,}067{,}200 \text{ s}$

يستخدم هذا المحوّل داخليًا واجهة JavaScript Date القياسية للتعامل مع السنوات الكبيسة والحالات الحدية في التقويم.

مشكلة عام 2038

تخزّن كثير من الأنظمة القديمة الطابعَ الزمني يونيكس في عدد صحيح موقّع بعرض 32 بتًا. أقصى قيمة موجبة يستوعبها هذا النوع هي 2,147,483,647، وتقابل اللحظة 2038-01-19 03:14:07 UTC. بعد تلك اللحظة يفيض العداد ويعود إلى أكبر قيمة سالبة في 32 بتًا، فتُفسّر تلك الأنظمة التاريخ على أنه 1901-12-13.

الأنظمة الحديثة ذات 64 بتًا لا تعاني هذه المشكلة؛ إذ يستطيع العدد الصحيح الموقّع بعرض 64 بتًا تمثيل طوابع زمنية تمتد نحو 292 مليار سنة مستقبلًا ومثلها ماضيًا — ما يتجاوز أي متطلب عملي. وتظل المشكلة قاصرة على الأنظمة المدمجة الموروثة وقواعد البيانات والبرمجيات غير المُحدَّثة، في حين انتقلت معظم أنظمة التشغيل ولغات البرمجة الشائعة إلى تخزين الوقت بعرض 64 بتًا قبل عام 2020.

ملاحظات عملية

المناطق الزمنية. الطابع الزمني يونيكس يُحصي دائمًا الثواني من منتصف ليل UTC بتاريخ 1970-01-01، ولا يتضمن أي معلومة عن المنطقة الزمنية. عند تحويل وقت محلي إلى epoch يجب أولًا تحويله إلى UTC. يعتمد هذا المحوّل منتصف ليل UTC أساسًا لأي إدخال يقتصر على التاريخ دون الوقت، وهو التفسير المعياري.

الثواني الكبيسة. لا يأخذ نظام epoch الثواني الكبيسة بالحسبان، إذ يفترض 86,400 ثانية بالضبط في كل يوم. وبذلك لا يعادل الطابع الزمني يونيكس التوقيت الذري الدولي (TAI) بدقة. غير أن هذا الفارق التراكمي — نحو 27 ثانية حتى عام 2024 — لا أثر له في التطبيقات البرمجية الاعتيادية.

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