كيف تستخدم محوّل الطابع الزمني Unix
- الصق طابعًا زمنيًا Unix. يتعرّف المحوّل على ما إذا كان بالثواني أو بالملي ثانية.
- اقرأ التاريخ بتوقيت UTC، وبمنطقتك الزمنية المحلية، وبتنسيق ISO 8601.
- للتحويل في الاتجاه المعاكس، اختر تاريخًا ووقتًا وانسخ الطابع الزمني الناتج.
تُحسب التحويلات في متصفحك باستخدام ساعة جهازك وإعدادات منطقته الزمنية؛ لا يُرسل أي شيء إلى خادم ولا يُخزَّن عليه.
ما هو الطابع الزمني Unix؟
الطابع الزمني Unix (ويُسمّى أيضًا epoch time أو وقت POSIX) هو عدد الثواني المنقضية منذ حقبة Unix: 1970-01-01T00:00:00Z، أي منتصف الليل بتوقيت UTC في 1 يناير 1970. والتواريخ السابقة لهذه الحقبة أعداد سالبة.
تحظى الطوابع الزمنية بالشعبية لأنها عدد صحيح واحد، مستقل عن المناطق الزمنية والتوقيت الصيفي، وسهل المقارنة والترتيب، ومضغوط عند التخزين. أما التحويل إلى التوقيت المحلي فمسألة عرض تُعالَج في اللحظة الأخيرة.
1700000000 → 2023-11-14T22:13:20Z
0 → 1970-01-01T00:00:00Z
-86400 → 1969-12-31T00:00:00Zالثواني مقابل الملي ثانية
تستخدم أدوات Unix وPHP وtime.time() في Python ومعظم قواعد البيانات الثواني. بينما تستخدم Date.now() في JavaScript وSystem.currentTimeMillis() في Java وكثير من واجهات JSON البرمجية الملي ثانية. بالنسبة لتواريخ الوقت الحاضر، تتكوّن القيمة بالثواني من 10 أرقام والقيمة بالملي ثانية من 13 رقمًا. والخلط بينهما هو أكثر أخطاء الطوابع الزمنية شيوعًا على الإطلاق:
new Date(1700000000) // Tue Jan 20 1970 (تُعامَل كملي ثانية!)
new Date(1700000000 * 1000) // Tue Nov 14 2023الثواني الكبيسة لا تُحتسب
يفترض وقت Unix أن كل يوم يتكوّن من 86,400 ثانية بالضبط. وعند إدراج ثانية كبيسة في UTC، لا يحسبها وقت Unix، لذلك لا يساوي الطابع الزمني العدد الحقيقي لثواني SI المنقضية منذ 1970. وهذا لا يهم في جميع التطبيقات تقريبًا، ويُبقي حسابات التواريخ بسيطة.
أخطاء شائعة
مشكلة عام 2038
الأنظمة التي تخزّن الطوابع الزمنية كـعدد صحيح بإشارة من 32 بت لا تستطيع العدّ إلا حتى 2,147,483,647، أي 2038-01-19T03:14:07Z. وبعد ثانية واحدة تفيض القيمة وتلتفّ إلى عدد سالب يمثّل تاريخًا في ديسمبر 1901. تستخدم أنظمة التشغيل ولغات البرمجة الحديثة وقتًا من 64 بت، لكن الأجهزة المدمجة وصيغ الملفات القديمة وأعمدة قواعد البيانات المعرَّفة كأعداد صحيحة من 32 بت تبقى معرّضة للخطر. استخدم أعدادًا صحيحة من 64 بت أو أنواع التاريخ/الوقت الأصلية لأي شيء قد يخزّن تواريخ مستقبلية.
تسلّل التوقيت المحلي
تحليل سلسلة تاريخ من دون منطقة زمنية، مثل 2024-03-10 02:30، يستخدم المنطقة المحلية للجهاز، وقد ينتج طوابع زمنية مختلفة على خوادم مختلفة، أو وقتًا غير صالح أثناء الانتقال إلى التوقيت الصيفي أو منه. أضف دائمًا الإزاحة أو Z.
ISO 8601
لتبادل البيانات بصيغة يقرؤها الإنسان، يُعدّ ISO 8601 (وملفّه الخاص بالإنترنت، RFC 3339) هو المعيار: 2023-11-14T22:13:20Z أو 2023-11-14T23:13:20+01:00. ومثل الطوابع الزمنية، تُرتَّب سلاسل ISO 8601 بتوقيت UTC ترتيبًا صحيحًا كنص عادي.
الحصول على الطابع الزمني الحالي في الشيفرة
| البيئة | الثواني منذ الحقبة |
|---|---|
| سطر الأوامر Shell (Linux وmacOS) | date +%s |
| Python | import time; int(time.time()) |
| JavaScript | Math.floor(Date.now() / 1000) |
| PHP | time() |
| MySQL | SELECT UNIX_TIMESTAMP(); |
| PostgreSQL | SELECT EXTRACT(EPOCH FROM now()); |
لتحويل طابع زمني إلى تاريخ في سطر الأوامر، استخدم date -u -d @1700000000 على Linux (GNU date) أو date -u -r 1700000000 على macOS.
exp وiat وnbf كطوابع زمنية Unix بالثواني. وتحوّلها لك أداة فك ترميز JWT. أما للمعرّفات المرتبة زمنيًا التي تتضمن طابعًا زمنيًا بالملي ثانية، فانظر مولّد UUID v7.الأسئلة الشائعة
هل الطابع الزمني Unix هو نفسه في كل منطقة زمنية؟
نعم. فهو يعدّ الثواني منذ لحظة ثابتة بتوقيت UTC، لذلك يكون متطابقًا في كل مكان في أي لحظة معينة. ولا يختلف إلا تحويله إلى التوقيت المحلي.
كيف أميّز الثواني من الملي ثانية؟
عُدّ الأرقام. التواريخ الحالية تتكوّن من 10 أرقام بالثواني و13 رقمًا بالملي ثانية. وظهور «تاريخ» في يناير 1970 يعني عادةً أن قيمة بالثواني قُرئت على أنها بالملي ثانية؛ أما ظهور تاريخ بعد عشرات آلاف السنين في المستقبل فيعني العكس.
ماذا سيحدث في عام 2038؟
لن تتعطل إلا البرامج التي تخزّن الوقت في عدد صحيح بإشارة من 32 بت. أما الطوابع الزمنية من 64 بت فلن تفيض قبل مليارات السنين.
هل يمكن أن يكون الطابع الزمني Unix سالبًا؟
نعم. تمثّل القيم السالبة لحظات قبل 1 يناير 1970، مع أن بعض الأنظمة وواجهات API الأقدم لا تقبلها.
آخر تحديث