محول الطابع الزمني يونكس

تحويل أي طابع زمني ليونكس إلى تاريخ ووقت مقروءين للبشر.

برنامجنا:

• يكتشف تلقائياً الثواني (10 أرقام) والمللي ثانية (13 رقماً)
• يعرض التوقيت العالمي المنسق (UTC) والتوقيت المحلي
• يعرض تنسيقات متعددة تشمل ISO 8601 و RFC 2822

تحويل أي تاريخ ووقت إلى الطابع الزمني الخاص به في يونكس.

حدد تاريخاً، اختر منطقتك الزمنية، واحصل على وقت الحقبة بالثواني والمللي ثانية.

مثالي لـ:

• تطوير واجهات برمجة التطبيقات (APIs)
• استعلامات قواعد البيانات
• تصحيح أخطاء الوقت

وقت يونكس هو نظام لتتبع لحظة زمنية معينة باعتبارها عدد الثواني المنقضية منذ حقبة يونكس، والتي تُعرّف بأنها 00:00:00 بالتوقيت العالمي المنسق (UTC) في 1 يناير 1970. يوثق معهد مهندسي الكهرباء والإلكترونيات (IEEE) ومجموعة The Open Group هذا في معيار POSIX (IEEE Std 1003.1)، حيث يسمى رسمياً "الثواني منذ الحقبة".

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

إن تخزين الوقت كعدد صحيح، كما تشير وثائق MDN Web Docs لكائن التاريخ في JavaScript، يجعل العمليات الحسابية والمقارنات بسيطة للغاية مقارنة بتحليل سلاسل التواريخ المنسقة.

يحسب الطابع الزمني ليونكس المكون من 10 أرقام الثواني منذ الحقبة، بينما يحسب الطابع الزمني المكون من 13 رقماً المللي ثانية، ويعد الخلط بينهما خطأ التحويل الأكثر شيوعاً.

وفقاً لموقع MDN Web Docs، تعود دالتا JavaScript المتمسلتان بـ Date.now() و getTime() بقيم بالمللي ثانية، لذا فإن 1700000000000 تعد قيمة صالحة لـ JavaScript. في المقابل، تعمل دالات POSIX C مثل time() ودالة time.time() في بايثون مع الاقتطاع، بالإضافة إلى معظم قواعد بيانات SQL وأمر Bash date +%s، بالثواني (1700000000).

للتحويل بينهما، اضرب الثواني في 1,000 أو اقسم المللي ثانية على 1,000.

يكتشف برنامجنا وحدة القياس تلقائياً من خلال عدد الأرقام، ولكن عند كتابة الكود البرمجى، يجب عليك دائماً التأكد من وحدة القياس التي تتوقعها لغتك أو واجهة برمجة التطبيقات (API) لتجنب تواريخ تقع في عام 1970 أو بعد آلاف السنين في المستقبل.

يمكنك إنشاء الطابع الزمني الحالي ليونكس باستدعاء برمجي واحد في كل لغة برمجة تقريباً.

• في JavaScript، يوصي موقع MDN Web Docs باستخدام Math.floor(Date.now() / 1000) للثواني أو Date.now() للملي ثانية.
• في Python، تعيد الدالة time.time() قيمة عشرية للثواني منذ الحقبة، مطابقة لدالة مكتبة C المسمى time() والمعرفة بواسطة POSIX.
• على سطر الأوامر (Command Line)، يطبع أمر date +%s التابع لـ GNU coreutils الطابع الزمني الحالي بدقة الثواني، بينما تستخدم PHP الدالة time() وتستخدم Go الدالة time.Now().Unix().
• تعرض محركات SQL دالات مثل UNIX_TIMESTAMP() في MySQL و EXTRACT(EPOCH FROM now()) في PostgreSQL.

تشير كل هذه الطرق إلى نفس نقطة البداية لعام 1970 UTC، لذا فإن القيم قابلة للتبادل بشكل مباشر بمجرد توحيد وحدة الثواني مقابل المللي ثانية.

استخدم طابعاً زمنياً ليونكس للتخزين والعمليات الحسابية، واستخدم ISO 8601 للتبادل المقروء للبشر والسجلات.

ISO 8601 هو المعيار الدولي لتمثيل التواريخ والأوقات كسلاسل نصية مثل 2023-11-14T22:13:20Z، حيث يفصل الحرف الكبير T بين التاريخ والوقت، ويشير الحرف Z في النهاية إلى التوقيت العالمي المنسق (توقيت زولو). هذه الحروف حساسّة لحالة الأحرف (Lower/Uppercase)، لذا إذا كنت ترتب سلاسل منقولة من مصادر مختلطة، فإن تمريرة سريعة عبر محول حالة الأحرف تبقيها قابلة للتحليل. يصنف معيار RFC 3339 التابع لـ IETF تنسيق ISO 8601 للاستخدام على الإنترنت وهو ما تتبناه معظم واجهات برمجة تطبيقات JSON لحقول التاريخ، نظراً لأن JSON نفسه (RFC 8259) لا يحتوي على نوع تاريخ أصلي.

العدد الصحيح ليونكس يكون أكثر إيجازاً ومحايداً تجاه المناطق الزمنية ولكنه غير معبر عن نفسه ذاتياً، في حين أن سلسلة ISO 8601 مقروءة فوراً. تخزن العديد من الأنظمة العدد الصحيح داخلياً وتقوم بتحويله إلى تنسيق ISO 8601 عند حدود واجهة برمجة التطبيقات للحصول على ميزات الاثنين.

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

تعد قاعدة بيانات المناطق الزمنية لـ IANA (قاعدة بيانات tz) هي المصدر الرسمي الذي تستخدمه أنظمة التشغيل واللغات لربط لحظة زمنية بالتوقيت المحلي، بما في ذلك قواعد التوقيت الصيفي التاريخية.

أفضل ممارسة، والتي رددها موقع MDN Web Docs وعدد لا يحصى من أدلة الهندسة، هي تخزين ونقل الطوابع الزمنية بالتوقيت العالمي المنسق (UTC) والتحويل إلى المنطقة الزمنية المحلية للمشاهد فقط في وقت العرض. هذا يلغي أي غموض حول انتقالات التوقيت الصيفي ويجعل المقارنات عبر المناطق الجغرافية موثوقة وقابلة للتكرار.

مشكلة عام 2038 هي اللحظة التي ستتجاوز فيها الأعداد الصحيحة ذات الـ 32 بت والموقعة التي تخزن وقت يونكس الحد الأقصى، وذلك في تمام الساعة 03:14:07 بالتوقيت العالمي المنسق (UTC) يوم 19 يناير 2038.

تصل القيمة القصوى للقيمة ذات الـ 32 بت الموقعة إلى 2,147,483,647 ثانية؛ وبعد ثانية واحدة، تتجاوز القيمة سعتها لتتحول إلى عدد سالب كبير، وهو ما تفسره الأكواد البرمجية الساذجة على أنه 19 ديسمبر 1901. يشبه هذا مخاوف التاريخ المتعلقة بمشكلة عام 2000 ولكنه متجذر في العرض الثابت لنوع C time_t على المنصات القديمة.

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

تعتبر طوابع وقت يونكس العمود الفقري لمعالجة الوقت في الأنظمة الخلفية وسجلات الأنشطة وواجهات برمجة التطبيقات (APIs) لأنها تقوم بعمليات الترتيب والمقارنة كأعداد صحيحة عادية.

تقوم قواعد البيانات بتخزين أعمدة created_at و updated_at كقيم حقبة زمنية أو أنواع طوابع زمنية مشتقة منها، وتستخدم طبقات التخزين المؤقت الطوابع الزمنية لانتهاء الصلاحية لإبطال الإدخالات. تعتمد الرموز الأمنية عليها أيضاً: معيار JWT، RFC 7519، يحدد مطالبات الصلاحية (exp) والإصدار (iat) كقيم NumericDate، وهي حرفياً الثواني المنقضية منذ حقبة يونكس.

تستخدم سجلات الأنشطة الموزعة وتدفقات الأحداث الطوابع الزمنية لإنشاء التسلسل، وتقوم أدوات تحديد معدل الطلبات بمقارنة الحقبة الحالية مقابل النوافذ المخزنة. طبيعتها التي لا تتأثر بلغة معينة تجعلها مثالية لتمرير الوقت عبر حدود الخدمات المختلفة.

تمثل طوابع وقت يونكس السالبة اللحظات التي تسبق حقبة يونكس، لذا فإن -86400 يوافق 31 ديسمبر 1969 الساعة 00:00:00 بالتوقيت العالمي المنسق (UTC). يسمح تعريف POSIX بأن يكون عدد الثواني سالباً، واللغات مثل JavaScript تحترم هذا: توثق وثائق MDN Web Docs أن كائن Date يقبل قيم المللي ثانية السالبة للتعبير عن تواريخ ما قبل عام 1970.

هذا مفيد للبيانات التاريخية، أو تواريخ الميلاد، أو السجلات الأرشيفية.

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

• الخطأ الأكثر تكراراً هو الخلط بين الثواني والمللي ثانية، مما ينتج عنه تواريخ تفصلها عقود أو عالقة في عام 1970. تأكد دائماً من الوحدات التي يستخدمها مصدرك قبل التحويل، نظراً لأن JavaScript تُصدر المللي ثانية بينما تُصدر معظم الأنظمة الخلفية الثواني.
• المأزق الثاني هو افتراض أن الطابع الزمني يحمل منطقة زمنية؛ فهو لا يحملها، لذا فإن تطبيق الإزاحة المحلية مرتين ينتج عنه أوقات غير صحيحة للساعة.
• تشمل الأخطاء الأخرى تجاهل حد عام 2038 على حقول الـ 32 بت، وتوقع أن يأخذ وقت يونكس في الاعتبار الثواني الكبيسة، وهو ما يستبعده POSIX صراحةً.
• وأخيراً، تجنب تحليل سلاسل التواريخ المنسقة يدوياً؛ استخدم المكتبات القياسية وفضل استخدام معيار ISO 8601 (RFC 3339) للتبادل، كما تنصح وثائق MDN Web Docs، لتجنب التنسيقات الغامضة مثل الشهر/اليوم مقابل اليوم/الشهر.