الطابع الزمني Unix: كيف يعمل، وكيف تحوله، وما علاقته بـ Cron؟

إذا فتحت ملف سجلات، أو استجابة من واجهة برمجة، أو جدولًا في قاعدة بيانات، فقد ترى أرقامًا طويلة مثل 1791460800 بدل التواريخ. هذا هو الطابع الزمني Unix (Unix timestamp أو Epoch time)، أبسط طريقة لتمثيل لحظة زمنية: رقم واحد، بلا منطقة زمنية، بلا صيغة تاريخ. هذا الدليل يشرح كيف يعمل، وكيف تتجنب الأخطاء الشائعة، ثم يقدم أساسيات صيغة Cron لجدولة المهام.

التعريف

Unix timestamp = عدد الثواني منذ 1970-01-01 00:00:00 UTC.

القيم السالبة تمثل ما قبل 1970.

لماذا هو مفيد؟

• مستقل عن المنطقة الزمنية: اللحظة نفسها لها الرقم نفسه في الرياض والقاهرة ولندن.
• سهل المقارنة والحساب: الفرق بين طابعين = عدد الثواني بينهما مباشرة.
• مضغوط: رقم واحد بدل نص طويل.

حساب سريع

مثال: انتهاء صلاحية رمز بعد 24 ساعة = الطابع الحالي + 86,400.

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

أكثر خطأ شائع في التعامل مع الطوابع:

قاعدة الخانات: للتواريخ الحالية، 10 خانات = ثوانٍ، 13 خانة = مللي ثانية.

إذا رأيت تاريخًا في عام 1970 فغالبًا مررت ثواني إلى دالة تتوقع مللي ثانية. وإذا رأيت عامًا بعيدًا مثل 58000 فالعكس.

// JavaScript
Date.now();                          // مللي ثانية
Math.floor(Date.now() / 1000);       // ثوانٍ
new Date(1791460800 * 1000).toISOString(); // '2026-10-08T12:00:00.000Z'

# Python
import time, datetime
int(time.time())  # ثوانٍ
datetime.datetime.fromtimestamp(1791460800, datetime.timezone.utc)

# Linux
date +%s                 # الطابع الحالي
date -u -d @1791460800   # تحويل إلى تاريخ (GNU)

محول Unix timestamp يتعرف على الوحدة تلقائيًا ويعرض التاريخ بتوقيت UTC وتوقيتك المحلي.

المناطق الزمنية

الطابع نفسه لا يحمل منطقة زمنية؛ المنطقة تدخل فقط عند العرض:

1791460800 →
  UTC:            2026-10-08 12:00
  الرياض (UTC+3): 2026-10-08 15:00
  دبي (UTC+4):    2026-10-08 16:00
  القاهرة (UTC+3 صيفًا حتى 29 أكتوبر): 2026-10-08 15:00

القاعدة الذهبية: خزّن بالطابع أو بـ UTC، واعرض بالتوقيت المحلي. للتفاصيل حول التوقيت الصيفي وفروق المدن راجع دليل المناطق الزمنية.

ISO 8601 بديل مقروء

2026-10-08T12:00:00Z (حرف Z يعني UTC) أو 2026-10-08T15:00:00+03:00. مقروء للإنسان، ويحمل الإزاحة، ويُرتَّب أبجديًا بشكل صحيح. شائع في JSON؛ راجع دليل أساسيات JSON.

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

لأن الطابع عدد ثوانٍ، فالفرق بين لحظتين عملية طرح بسيطة:

موعد الإطلاق:  1798761600  (2027-01-01 00:00 UTC)
الآن:          1791460800  (2026-10-08 12:00 UTC)
الفرق:         7,300,800 ثانية ÷ 86,400 = 84.5 يومًا

انتبه إلى أن “يوم” بالتوقيت المحلي قد يكون 23 أو 25 ساعة في البلدان التي تطبق التوقيت الصيفي، فاستخدم مكتبات التواريخ عند الحساب بالأيام التقويمية. ولحساب الأيام بين تاريخين دون برمجة راجع دليل حساب الأيام بين تاريخين.

مشكلة عام 2038

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

• معظم أنظمة التشغيل واللغات الحديثة انتقلت إلى 64 بت (يكفي لمليارات السنين).
• الخطر الباقي في: أنظمة مدمجة قديمة، وأعمدة قواعد بيانات من نوع INT 32 بت، وصيغ ملفات قديمة.
• في MySQL نوع TIMESTAMP كان محدودًا بعام 2038؛ استخدم DATETIME أو BIGINT للتواريخ البعيدة.

الثواني الكبيسة

Unix time يتجاهل الثواني الكبيسة: كل يوم 86,400 ثانية بالضبط. هذا يبسّط الحساب، والفرق لا يهم معظم التطبيقات.

أساسيات Cron

Cron هو مجدول المهام في أنظمة Unix، ويستخدم صيغته أيضًا GitHub Actions وKubernetes وخدمات السحابة. السطر يتكون من 5 حقول:

┌───── الدقيقة (0–59)
│ ┌───── الساعة (0–23)
│ │ ┌───── يوم الشهر (1–31)
│ │ │ ┌───── الشهر (1–12)
│ │ │ │ ┌───── يوم الأسبوع (0–6، الأحد = 0)
│ │ │ │ │
* * * * *  الأمر

أمثلة جاهزة

تنبيه: Cron يعمل بالمنطقة الزمنية للخادم، وكثير من الخوادم والخدمات السحابية على UTC. “9 صباحًا بتوقيت الرياض” على خادم UTC تعني 0 6 * * *.

مولد تعابير Cron يشرح أي تعبير بالعربية ويعرض مواعيد التشغيل القادمة.

أخطاء شائعة

1. الخلط بين الثواني والمللي ثانية (تاريخ 1970 أو عام 58000).
2. تخزين الوقت المحلي بدل UTC ثم ضياع ساعات عند تغيير التوقيت الصيفي.
3. أعمدة 32 بت لتواريخ بعد 2038 (عقود الإيجار الطويلة، الضمانات).
4. نسيان منطقة الخادم في Cron.
5. في Cron: تحديد يوم الشهر ويوم الأسبوع معًا يعني “أو” لا “و” في معظم التطبيقات.