صيغة Unix Timestamp مقابل ISO 8601: أيهما تختار؟

إذا سبق لك دمج نظامين يخزّنان التواريخ بصيغتين مختلفتين، فأنت تعرف جيداً حجم الإزعاج الناتج عن ذلك. API واحد يُعيد 1714521600، وآخر يُعيد 2024-05-01T00:00:00Z، وفجأة تجد نفسك تكتب منطق تحويل في منتصف الليل. اختيار صيغة Unix timestamp المناسبة مقابل ISO 8601 منذ البداية يوفّر عليك ساعات من التصحيح ويمنع الأخطاء الصامتة في بيئة الإنتاج. كلا الصيغتين مستخدمتان على نطاق واسع، ولكل منهما مزاياها الحقيقية، ولا توجد واحدة "أفضل" بشكل مطلق. المهم هو أن تفهم متى تناسبك كل صيغة ولماذا يُكلّفك الاختيار الخاطئ وقتاً وجهداً غير ضروريين.

ما هي صيغة Unix Timestamp؟

Unix timestamp (المعروف أيضاً بـ Unix time أو epoch time) هو عدد صحيح يمثّل عدد الثواني المنقضية منذ Unix epoch: الأول من يناير 1970، الساعة 00:00:00 بتوقيت UTC. صيغة Unix time مستقلة عن المناطق الزمنية بطبيعتها لأنها تُشير دائماً إلى UTC، ولا يوجد أي غموض يتعلق بالتوقيت الصيفي أو فوارق التوقيت الإقليمية.

على سبيل المثال، Unix timestamp 1714521600 يمثّل لحظة زمنية محددة بدقة، بغض النظر عن مكانك في العالم. كثير من الأنظمة الحديثة تمتد لتشمل المللي ثانية (1714521600000) أو الميكرو ثانية لمزيد من الدقة. يمكنك التعرف أكثر على هذه الاختلافات في دليلنا حول الثواني مقابل المللي ثانية مقابل الميكرو ثانية في Unix timestamps.

من الناحية التقنية، Unix timestamp مجرد رقم. هذه البساطة هي أكبر نقطة قوة له، وفي الوقت ذاته سبب أكبر مشكلة فيه وهي صعوبة القراءة المباشرة.

للاطلاع على خلفية أعمق حول أصل هذا المفهوم، راجع مقالتنا عن epoch time وأسسه.

ما هي صيغة تاريخ ISO 8601؟

ISO 8601 هو معيار دولي نشرته المنظمة الدولية للمعايير يحدد طريقة تمثيل التواريخ والأوقات كسلاسل نصية. يبدو تاريخ ISO 8601 النموذجي كما يلي: 2024-05-01T00:00:00Z.

تفصيل هذه الصيغة:

• 2024-05-01 — التاريخ بصيغة YYYY-MM-DD
• T — فاصل بين التاريخ والوقت
• 00:00:00 — الوقت بصيغة HH:MM:SS
• Z — يشير إلى توقيت UTC (يمكن أيضاً استخدام إزاحات مثل +05:30)

ISO 8601 هو الركيزة الأساسية لـ معيار RFC 3339 المستخدم على نطاق واسع في بروتوكولات الإنترنت. هو مقروء للإنسان، وقابل للترتيب كسلسلة نصية، وغير ملتبس عبر مختلف اللغات والمناطق. على عكس كتابة "05/01/2024" التي تعني الأول من مايو في الولايات المتحدة لكنها تعني الخامس من يناير في أوروبا، فإن ISO 8601 متسق عالمياً.

الفروق الرئيسية في لمحة سريعة

متى تستخدم صيغة Unix Timestamp؟

تتألق صيغة Unix time في حالات محددة وواضحة. استخدمها عندما:

1. إجراء العمليات الحسابية على التواريخ

حساب المدد الزمنية أمر بسيط جداً مع Unix timestamps؛ لمعرفة كم مضى من الثواني، تطرح عدداً صحيحاً من آخر. أما مع سلاسل ISO 8601، فيجب أولاً تحليل كليهما إلى كائنات datetime ثم حساب الفرق. في العمليات عالية التردد (كتسجيل ملايين الأحداث)، يتراكم عبء التحليل هذا بشكل ملحوظ.

2. تخزين التواريخ في قواعد البيانات

أعمدة الأعداد الصحيحة أسرع في الفهرسة والمقارنة من أعمدة السلاسل النصية. إذا كنت تُنفّذ استعلامات مثل "أعطني جميع الأحداث في آخر 7 أيام"، فمقارنة عددين صحيحين أكثر كفاءة من تحليل السلاسل النصية ومقارنتها. يتناول دليلنا التفصيلي حول Unix timestamps في قواعد البيانات استراتيجيات الفهرسة وأنماط الاستعلام بعمق.

3. التواصل بين الخدمات الداخلية

عندما يحتاج خدمتان خلفيتان تتحكم فيهما إلى تبادل الطوابع الزمنية، تُقلل صيغة Unix من تعقيد التحليل. كلا الطرفين يتفقان على عقد الأعداد الصحيحة، ولا يوجد خطر من سوء تفسير سلاسل المناطق الزمنية.

4. منطق انتهاء الصلاحية وTTL

رموز JWT وإدخالات ذاكرة التخزين المؤقت وانتهاء صلاحية الجلسات تُعبَّر عنها بشكل شبه عالمي كـ Unix timestamps. المطالبة exp في JSON Web Token (JWT) هي Unix timestamp لهذا السبب تحديداً: مقارنة exp > Date.now() / 1000 هي عملية مقارنة عدد صحيح واحدة سريعة.

5. تجنب أخطاء المناطق الزمنية

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

كن على دراية بـ مشكلة عام 2038 إذا كنت تستخدم أعداداً صحيحة موقّعة 32-بت لتخزين Unix timestamps — استخدم دائماً أعداداً صحيحة 64-بت في الأنظمة الحديثة.

متى تستخدم صيغة تاريخ ISO 8601؟

تتفوق صيغة تاريخ ISO 8601 في السياقات التي يحتاج فيها البشر أو الأنظمة الخارجية إلى قراءة التواريخ أو كتابتها أو التحقق منها دون تشغيل كود.

1. استجابات API المستهلَكة من أطراف خارجية

إذا كنت تبني API عاماً، فإن إعادة "created_at": "2024-05-01T12:30:00Z" أكثر ودية للمطورين بكثير من "created_at": 1714562200. يمكن للمطورين الخارجيين فهم القيمة فوراً دون الحاجة إلى تحويلها. كثير من أدلة أسلوب API، بما فيها تلك الخاصة بـ Stripe و GitHub، تعتمد ISO 8601 افتراضياً لهذا السبب.

2. ملفات السجلات ومسارات التدقيق

السجلات يقرأها البشر خلال الحوادث. سطر سجل يقول [2024-05-01T14:22:05Z] ERROR: payment failed قابل للتنفيذ فوراً. أما سجل يحتوي على [1714569725] ERROR: payment failed فيُجبر القارئ على تحويل الطابع الزمني قبل أن يبدأ التصحيح.

3. التدويل والتوطين

يتضمن ISO 8601 معلومات إزاحة المنطقة الزمنية بشكل صريح. عندما يحتاج نظامك إلى الحفاظ على التوقيت المحلي الأصلي للمستخدم (مثلاً، حدث تقويم أُنشئ الساعة 9:00 صباحاً في طوكيو)، يلتقط ISO 8601 مع الإزاحة الصحيحة (2024-05-01T09:00:00+09:00) هذه النية. Unix timestamp وحده لا يمكنه إخبارك بالمنطقة الزمنية التي كان فيها المستخدم عند إنشاء الحدث.

4. ملفات الإعداد وصيغ تبادل البيانات

ملفات JSON و YAML و CSV التي يحررها البشر يجب أن تستخدم ISO 8601. إذا احتاج مطور إلى تحديد تاريخ انتهاء صلاحية يدوياً في ملف إعداد، فكتابة 2025-01-01T00:00:00Z أقل عرضة للخطأ بكثير من حساب وكتابة Unix timestamp يدوياً.

أمثلة برمجية بـ JavaScript و Python

JavaScript: التحويل بين الصيغتين

// الحصول على Unix timestamp الحالي (بالثواني)
const unixNow = Math.floor(Date.now() / 1000);
console.log(unixNow); // مثال: 1714521600

// تحويل Unix timestamp إلى سلسلة ISO 8601
const isoString = new Date(unixNow * 1000).toISOString();
console.log(isoString); // "2024-05-01T00:00:00.000Z"

// تحويل سلسلة ISO 8601 مجدداً إلى Unix timestamp
const parsed = new Date("2024-05-01T00:00:00Z");
const backToUnix = Math.floor(parsed.getTime() / 1000);
console.log(backToUnix); // 1714521600

// حساب المدة بين Unix timestamps (لا حاجة للتحليل)
const start = 1714521600;
const end = 1714608000;
const durationSeconds = end - start;
console.log(`Duration: ${durationSeconds / 3600} hours`); // 24 hours

Python: العمل مع كلتا الصيغتين

import time
from datetime import datetime, timezone

# الحصول على Unix timestamp الحالي
unix_now = int(time.time())
print(unix_now)  # مثال: 1714521600

# تحويل Unix timestamp إلى سلسلة ISO 8601
dt = datetime.fromtimestamp(unix_now, tz=timezone.utc)
iso_string = dt.isoformat()
print(iso_string)  # "2024-05-01T00:00:00+00:00"

# تحويل سلسلة ISO 8601 مجدداً إلى Unix timestamp
parsed_dt = datetime.fromisoformat("2024-05-01T00:00:00+00:00")
back_to_unix = int(parsed_dt.timestamp())
print(back_to_unix)  # 1714521600

# حساب المدة - بسيط جداً مع Unix timestamps
start = 1714521600
end = 1714608000
duration_hours = (end - start) / 3600
print(f"Duration: {duration_hours} hours")  # 24.0 hours

مثال عملي: نظام حجز

تخيّل أنك تبني API لحجز الفنادق. مستخدم في نيويورك يحجز غرفة لتسجيل الوصول في 15 يونيو 2024 الساعة 3:00 مساءً بالتوقيت المحلي. إليك كيف تتصرف الصيغتان بشكل مختلف في الواقع العملي.

التخزين كـ Unix timestamp: تحوّل التوقيت المحلي للمستخدم إلى UTC وتخزّن 1718470800. هذا مضغوط وسريع في الاستعلام. لكن عندما ينظر موظفو الفندق في نيويورك إلى سجل قاعدة البيانات الخام، يرون رقماً ويحتاجون إلى أداة لفك تشفيره. والأسوأ، إذا نسيت تحويل التوقيت المحلي إلى UTC قبل التخزين، أدخلت خطأ صامتاً مقداره 4 ساعات (نيويورك UTC-4 في الصيف).

التخزين كـ ISO 8601: تخزّن 2024-06-15T15:00:00-04:00. الإزاحة محفوظة. يمكن للموظفين قراءة السجل مباشرة. نية المنطقة الزمنية الأصلية لا تضيع. لكن مقارنات السلاسل النصية في SQL أبطأ قليلاً، وحساب "كم ساعة حتى تسجيل الوصول" يتطلب تحليل السلسلة أولاً.

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

للاطلاع على شرح كامل لأنماط التحويل، راجع دليلنا الشامل لتحويل Unix timestamp إلى تاريخ.

توصية واضحة حسب حالة الاستخدام

بناءً على القيود الواقعية، إليك توصية مباشرة لكل سيناريو:

• التخزين في قواعد البيانات: استخدم Unix timestamp (عدد صحيح). فهرسة أسرع، لا تحليل للمناطق الزمنية، حجم أصغر.
• التواصل الداخلي بين الخدمات المصغّرة (microservices): استخدم Unix timestamp. كلا الطرفين يتحكمان في العقد ولا يقرأ أي إنسان الـ payload الخام.
• استجابات REST API العامة: استخدم ISO 8601. المطورون الخارجيون يحتاجون إلى قيم مقروءة وموثّقة ذاتياً.
• ملفات السجلات ومسارات التدقيق: استخدم ISO 8601. البشر يقرؤون السجلات تحت ضغط خلال الحوادث.
• انتهاء صلاحية JWT والجلسات: استخدم Unix timestamp. المواصفة تتطلبه والمقارنات عملية واحدة.
• ملفات الإعداد والمهام المجدوَلة: استخدم ISO 8601. البشر يكتبون هذه الملفات ويحررونها مباشرة.
• ميزات التقويم والجدولة: استخدم ISO 8601 مع إزاحة المنطقة الزمنية الصريحة. يحافظ على نية المنطقة الزمنية الأصلية للمستخدم.
• العمليات الحسابية على التواريخ في منطق التطبيق: حوّل إلى Unix timestamp أولاً، أجرِ الحسابات، ثم حوّل مجدداً إذا لزم الأمر.

للاطلاع على مجموعة أوسع من أفضل الممارسات للتعامل مع الطوابع الزمنية في الكود الخلفي، يتناول درسنا حول Unix timestamp للمطورين أنماط التخزين والتنسيق والتعامل مع المناطق الزمنية بالتفصيل.

خلاصة

الجدل بين صيغة Unix timestamp وصيغة تاريخ ISO 8601 ليس عن أيهما أفضل. بل هو عن اختيار الأداة المناسبة للمهمة المناسبة. Unix timestamps تنتمي إلى أعمدة قاعدة البيانات وعقود خدماتك الداخلية ومنطق انتهاء الصلاحية. ISO 8601 ينتمي إلى استجابات API والسجلات وأي ملف قد يفتحه إنسان. معظم أنظمة الإنتاج القوية تستخدم كليهما: التخزين كـ Unix time، والعرض كـ ISO 8601. إذا استوعبت هذا النمط الواحد، ستتجنب أكثر أخطاء معالجة التواريخ شيوعاً قبل أن تصل إلى بيئة الإنتاج.

توقف عن التخمين في صيغة التاريخ التي تستخدمها

جرّب أداة تحويل Unix Timestamp المجانية على unixtimestamp.app وحوّل بين Unix time و ISO 8601 فوراً — دون الحاجة إلى كتابة أي كود. الصق طابعاً زمنياً واحصل على تاريخ مقروء في ثوانٍ.

جرّب الأداة المجانية ←