تحويل Unix timestamp إلى تاريخ مقروء: ثوانٍ أم أجزاء من الألف؟
تفتح جدولاً في قاعدة بياناتك فتجد عموداً اسمه created_at وقيمته 1736035200. لا تخبرك هذه القيمة بشيء بمجرد النظر إليها. هي تاريخ بالتأكيد، لكن أي يوم؟ وبأي توقيت؟ ثم تجد في جدول آخر 1736035200000، وهو يبدو الرقم نفسه مع ثلاثة أصفار زائدة. هل هما اللحظة ذاتها؟ هذا بالضبط ما تحلّه أداة تحويل الطابع الزمني.
ما هو الطابع الزمني (Unix timestamp)
هو طريقة لتمثيل لحظة زمنية برقم واحد: عدد الثواني التي مرّت منذ منتصف ليلة الأول من يناير عام 1970 بالتوقيت العالمي المنسّق (UTC). تلك اللحظة تسمى «الحقبة» أو epoch. مثلاً الرقم صفر هو تلك اللحظة نفسها.
سبب انتشار هذا الأسلوب أنه لا يحتمل اللبس: رقم واحد لا يعتمد على لغة ولا على منطقة زمنية ولا على صيغة كتابة التاريخ. هل هو يوم/شهر أم شهر/يوم؟ مسألة لا وجود لها حين يكون التاريخ رقماً. ويسهل جمعه وطرحه ومقارنته، فاليوم الواحد هو 86400 ثانية بالضبط.
المشكلة الحقيقية: الوحدة
القصة التي تبدأ بسيطة تتعقّد عند أول نظام يستخدم وحدة أخرى. الوحدات الثلاث الشائعة:
- الثواني: عشر خانات في زماننا الحالي. تستخدمها أنظمة يونكس وكثير من قواعد البيانات.
- الملّي ثانية (أجزاء من الألف): ثلاث عشرة خانة. هي الصيغة الافتراضية في جافاسكربت وفي معظم الواجهات البرمجية الحديثة.
- الميكرو ثانية (أجزاء من المليون): ست عشرة خانة، وتظهر في سجلات الأداء الدقيقة.
الرقمان في بداية المقال هما اللحظة نفسها بوحدتين مختلفتين. وإن أدخلت الرقم الثاني إلى أداة تحسبه ثواني، فستحصل على تاريخ في عام لا يقع في حياتنا، بعد ألوف السنين من الآن. وإن فعلت العكس فستحصل على تاريخ في شهر يناير 1970 كأن الرقم صغير. الخطأ دائماً بفارق ألف ضعف، ولا يظهر أي تحذير.
محوّل الطابع الزمني في سهل يتعرف على الوحدة من طول الرقم، لكنه لا يطبّق اختياره بصمت. يعرض لك الوحدة التي افترضها بوضوح، فتتأكد منها بنظرة واحدة، وتبدّلها يدوياً إن كان الرقم غير معتاد.
خطوات الاستخدام
- الصق الرقم في الأداة، أو اختر الاتجاه المعاكس لتحويل تاريخ إلى رقم.
- انظر إلى الوحدة المكتشفة المعروضة بجانب النتيجة.
- اقرأ التاريخ بالتوقيت العالمي وبتوقيت جهازك المحلي.
- انسخ الصيغة التي تحتاجها.
المنطقة الزمنية: لماذا ترى ساعتين مختلفتين
الطابع الزمني نفسه لا يحمل منطقة زمنية. هو لحظة واحدة في العالم كله. الذي يختلف هو طريقة عرضها: الساعة التاسعة صباحاً في الرياض هي الثانية صباحاً في لندن شتاءً، وهي اللحظة ذاتها بالرقم ذاته. لذلك تعرض الأداة التوقيت العالمي بجانب توقيت جهازك، حتى لا تقع في الخطأ الشائع: أن تقارن ساعة من خادم بالتوقيت العالمي بساعة من هاتفك بتوقيتك المحلي، وتظن أن بينهما فرقاً.
القاعدة المفيدة في العمل البرمجي: خزّن الوقت دائماً كرقم أو بالتوقيت العالمي، ولا تحوّله إلى التوقيت المحلي إلا لحظة العرض على المستخدم.
أخطاء شائعة عند التعامل مع الطوابع الزمنية
- تخزين التاريخ نصاً: كتابة التاريخ كنص مثل «05/01/2025» تفتح باب اللبس بين اليوم والشهر، وتجعل الترتيب والمقارنة أصعب. الرقم أوضح وأسهل.
- الخلط بين الوحدات في نظام واحد: جدول يخزّن ثواني وآخر يخزّن ملّي ثانية، ثم يُربطان معاً في استعلام. اكتب الوحدة في اسم العمود، مثل created_at_ms، حتى لا تُنسى.
- الاعتماد على ساعة جهاز المستخدم: ساعة الهاتف قد تكون مضبوطة خطأً. الوقت المهم يُؤخذ من الخادم.
- حساب الأيام بضرب 86400 فقط: يصلح لفروق الزمن المجردة، لكنه لا يصلح لتحديد «اليوم نفسه بعد شهر»، لأن طول الشهر يتغيّر. وفي هذه الحالة تفيدك أداة الفرق بين تاريخين.
سيناريو واقعي
مطوّرة تحقق في بلاغ من عميل يقول إن اشتراكه انتهى قبل موعده. تفتح السجل فتجد حقل expires_at بقيمة من ثلاث عشرة خانة. تلصقها في الأداة فتكتشف أن الوحدة ملّي ثانية، والتاريخ الناتج هو الموعد الصحيح تماماً. المشكلة إذن ليست في الحقل بل في ملف تصدير يقرأ هذا الحقل على أنه ثوانٍ ويعرض تاريخاً خاطئاً. وجدت السبب في ثوانٍ لأن الأداة أوضحت لها الوحدة بدل أن تخمّنها. وإن كانت تقرأ رمزاً مميزاً فيه حقول وقت، فإن أداة فك ترميز JWT تحوّل حقلي الإصدار والانتهاء تلقائياً.
أسئلة شائعة
هل يتأثر الطابع الزمني بتوقيت الصيف؟
لا. هو عدّاد ثابت لا يعرف شيئاً عن التوقيت الصيفي. التغيير يحدث فقط عند تحويله إلى تاريخ محلي للعرض.
ما هي مشكلة عام 2038؟
الأنظمة التي تخزّن الثواني في عدد صحيح من اثنتين وثلاثين خانة تصل إلى حدّها الأقصى في يناير 2038، وبعدها يلتف الرقم إلى قيمة سالبة. الأنظمة الحديثة تستخدم أرقاماً أوسع فلا تتأثر، لكن الأنظمة القديمة المضمّنة قد تتأثر.
هل يمكن أن يكون الطابع الزمني سالباً؟
نعم، وهو يمثّل لحظة قبل عام 1970. الأرقام السالبة صالحة وتحوّلها الأداة إلى تاريخ كما هي.
لماذا يختلف الرقم قليلاً بين خادمين؟
لأن ساعة كل جهاز تنحرف قليلاً عن الوقت الحقيقي ما لم تُزامن دورياً مع مصدر دقيق. فرق ثانية أو ثانيتين بين جهازين أمر عادي، وفرق ساعات يعني خطأ في الإعداد.
هل تدعم الأداة الكسور العشرية؟
تقبل الأداة رقماً فيه جزء عشري مثل 1736035200.5 وتحسب التاريخ منه. لكن دقة التاريخ الناتج تصل إلى الملّي ثانية فقط، وصيغة ISO المعروضة تقف عند الثانية، فلا تعتمد على الأداة في فروق أصغر من ذلك.
هل يُرسل الرقم الذي أدخله إلى خادم؟
لا. التحويل يتم بالكامل داخل متصفحك دون إرسال أي شيء.
