معيار ISO 8601 وكيف تكتب تاريخًا بلا التباس
· 4 دقيقة قراءة
وُجد ISO 8601 لأن 03/04/2026 مارس في أمريكا وأبريل في سائر العالم. وكتابة 2026-04-03 تزيل الالتباس، وتُرتَّب ترتيبًا صحيحًا كنص، وهي ما ينبغي أن تقبله كل واجهة برمجية.
03/04/2026 هو الثالث من أبريل في معظم العالم، والرابع من مارس في الولايات المتحدة. ولا سبيل إلى معرفة المقصود من النص وحده، والقراءتان معقولتان تمامًا. وفي كل عام يُنتج هذا الالتباس مواعيد فائتة وحجوزات مكرَّرة وعُطلًا واحدًا على الأقل يبقى في الذاكرة.
ومعيار ISO 8601 هو المعيار الدولي الذي يزيله.
الصيغة الأساسية
2026-04-03T14:30:00Z
قراءةً من اليسار إلى اليمين، من أكبر وحدة إلى أصغرها:
2026-04-03— سنة وشهر ويوم، كلٌّ مسبوق بصفر عند اللزوم، وبهذا الترتيب دائمًاT— الفاصل بين التاريخ والوقت، وهو لازم في الصيغة الصارمة14:30:00— ساعات ودقائق وثوانٍ على مدار 24 ساعةZ— دالّة المنطقة. وZتعني UTC بالضبط
الترتيب هو المقصود. فلأن المكوّنات تسير من الأهم إلى الأقل أهمية، تُرتَّب سلسلة ISO 8601 ترتيبًا صحيحًا بوصفها نصًّا صرفًا. فـ 2026-04-03 يسبق 2026-04-10 في مقارنة نصية بسيطة، وهو ما لا تحققه أي صيغة شائعة أخرى. وهذه الخاصية وحدها تبرّر المعيار.
دوالّ المنطقة
ثلاث صيغ صحيحة، وهي تعني أشياء مختلفة:
| الصيغة | المعنى |
|---|---|
2026-04-03T14:30:00Z |
14:30 بتوقيت UTC. غير ملتبسة |
2026-04-03T14:30:00+05:45 |
14:30 بالتوقيت المحلي في منطقة تسبق UTC بخمس ساعات وخمس وأربعين دقيقة |
2026-04-03T14:30:00 |
14:30 في منطقة غير محددة. ليست طابعًا زمنيًّا |
والصيغة الثالثة هي مصدر المتاعب. فهي تاريخ ووقت محليان: قراءة ساعة حائط لا سبيل إلى وضعها على خط زمني. وتمريرها عبر حدود نظام على أمل أن يفترض الطرف الآخر المنطقة نفسها التي افترضتها أنت خلل ينتظر نشرًا في منطقة أخرى.
ولاحظ أيضًا ما ليس الفرق إياه: +05:45 يخبرك بفرق نيبال، لا بأن الطابع الزمني من نيبال. فالفروق ليست مناطق — إذ يتشارك الفرق الواحد عدة مناطق، وفرق المنطقة يتغير. احمل المعرِّف إلى جانبه إن احتجت إلى معرفة أين.
معيار RFC 3339، وهو الملمح الذي تريده غالبًا
معيار ISO 8601 واسع. فهو يجيز تواريخ الأسابيع (2026-W14-5)، والتواريخ الترتيبية (2026-093)، والوحدات الكسرية، وصيغة مبتورة تحذف القرن. وأغلب ذلك ليس ما تريده في واجهة برمجية.
أما RFC 3339 فملمح مشدود لبروتوكولات الإنترنت. يوجب التاريخ كاملًا، ويوجب دالّة منطقة، ويجيز الفاصل T أو مسافة. وحين يقول أحدهم «صيغة ISO» في سياق واجهة برمجية، فهو يعني RFC 3339 في الغالب الأعم.
قاعدة نافعة: اقبل كل ما يبتلعه محلّل جيد، ولا تُخرِج إلا RFC 3339 صارمًا بحرف Z.
المدد والفترات
أقل استعمالًا، ويحسن معرفتها حين تصادفها.
المدد تبدأ بحرف P من «period»، ويفصل T أجزاء التاريخ عن أجزاء الوقت:
P3Y6M4D— ثلاث سنوات وستة أشهر وأربعة أيامPT1H30M— ساعة وثلاثون دقيقةP1DT12H— يوم واثنتا عشرة ساعة
وحرف T ليس اختياريًّا: فـ P1M شهر واحد، وPT1M دقيقة واحدة. وهذا هو الخطأ الكلاسيكي في مدد ISO 8601.
الفترات تصل نقطتين بشَرطة مائلة: 2026-04-03T14:00Z/2026-04-03T16:00Z، أو نقطة ومدة: 2026-04-03T14:00Z/PT2H.
وبيانات HowTo المهيكلة في هذا الموقع تستعمل صياغة المدد — PT2M لمهمة من دقيقتين — لأن schema.org يشترط مدد ISO 8601.
تواريخ الأسابيع والفخ الكامن فيها
2026-W14-5 هو جمعة الأسبوع الرابع عشر بحسب ISO من سنة 2026. وأسابيع ISO تبدأ يوم الاثنين، والأسبوع 1 هو الأسبوع الذي يقع فيه أول خميس من يناير.
والنتيجة التي يتعثّر بها الناس: سنة أسبوع ISO ليست دائمًا سنة التقويم. فالأول من يناير 2027 يقع في الأسبوع 53 من سنة 2026 بحسب ISO. وشفرة التنسيق التي تقرن رقم أسبوع ISO بسنة تقويمية تُنتج تاريخًا خاطئًا بضعة أيام كل سنة — وفي أغلب اللغات تكاد محدّدات التنسيق تتطابق شكلًا (YYYY مقابل GGGG، أو %Y مقابل %G).
قواعد عملية
- خزّن بتوقيت UTC وأخرِج بحرف
Z. لـ2026-04-03T14:30:00Zمعنى واحد بالضبط في كل مكان. - لا تُخرِج أبدًا تاريخًا ووقتًا محليين عاريين عبر حدود. فإن لم تستطع إرفاق منطقة، فليس لديك طابع زمني.
- املأ كل شيء بالأصفار. فـ
2026-4-3ليس ISO 8601 صحيحًا، وإن قبله أغلب المحلّلات. - استعمل الفاصلين
-و:. فالصيغة المضغوطة (20260403T143000Z) مشروعة لكنها غير ودودة، وبعض المحلّلات ترفضها. - احتفظ بمعرّف المنطقة منفصلًا حين تحتاج إلى معرفة أين لا أي فرق فحسب. فـ
Europe/Londonينجو من تغيّر القواعد، و+01:00لا ينجو.
مزالق التحليل
حتى مع وجود معيار، فالتحليل هو الموضع الذي تسوء فيه الأمور.
بانية Date في جافاسكربت غير متسقة مع المدخلات غير المعيارية. فـ new Date('2026-04-03') تُحلَّل منتصفَ ليل بتوقيت UTC. أما new Date('2026-04-03T00:00:00') — بلا دالّة منطقة — فتُحلَّل منتصفَ ليل محليًّا. والفارق بينهما هو فرقك أنت، أي أن الشفرة نفسها تُنتج أيامًا مختلفة تبعًا لمكان تشغيلها. أدرِج دائمًا دالّة منطقة.
السنوات المكوّنة من رقمين ملتبسة وينبغي رفضها. فـ ISO 8601 يجيز صيغة مبتورة، ولا ينبغي أن يقبلها شيء تقريبًا. فـ 26-04-03 قد تكون 1926 أو 2026، والنافذة المنزلقة التي تحسم ذلك قرار سياسة مختبئ داخل محلّل.
كسور الثانية تتفاوت دقةً. فـ 14:30:00.5 و14:30:00.500 و14:30:00.500000 كلها صحيحة وكلها اللحظة نفسها. والمحلّل الذي يقارن السلاسل بدل اللحظات سيخالف في ذلك.
الفاصلة مشروعة. يجيز ISO 8601 كتابة 14:30:00,5 — بفاصلة عشرية — بل يفضّلها. وأغلب المحلّلات ترفضها. فإن كنت تستهلك بيانات من نظام أوروبي فكن مستعدًّا.
لمنتصف الليل كتابتان. فـ 24:00:00 في يوم هو اللحظة نفسها التي هي 00:00:00 في اليوم التالي، وكلتاهما ISO 8601 صحيح. أخرِج الصيغة الثانية، واقبل الاثنتين.
ملاحظة عن الترتيب
قابلية ترتيب ISO 8601 لا تصحّ إلا للسلاسل ذات تمثيل المنطقة نفسه. فـ 2026-04-03T14:00:00Z و2026-04-03T10:00:00-05:00 هما اللحظة نفسها، لكن الثانية تُرتَّب أولًا بوصفها سلسلة.
فإن كنت ترتّب طوابع زمنية بوصفها نصًّا — في ملف سجل، أو في اسم ملف، أو في عمود قاعدة بيانات من نوع نصي — فوحِّدها كلها أولًا على UTC بحرف Z. وإلا صار الترتيب خاصيةً للتنسيق لا للزمن.