مقال
مدد ISO 8601: ماذا يعني P1DT2H
تذكر استجابة من واجهة برمجة تطبيقات YouTube أن مدة أحد الفيديوهات هي PT4M13S. تحمل دعوة تقويم القيمة P15DT5H0M20S. يضع خادم دليل ما على حساب طابعاً زمنياً بالشكل 20260424174227.0Z، الذي يبدو مرتبطاً بما سبق لكنه في الواقع شيء مختلف تماماً. تخضع هذه السلاسل المضغوطة لقواعد يستحق الأمر معرفتها، لأن قراءتها بشكل خاطئ تحوّل الدقائق إلى أشهر. هذه جولة في تنسيق مدد ISO 8601: ماذا تعني الحروف، وأين يظهر هذا التنسيق، وأهم نقطة دقيقة فيه، وهي أن المدة المكتوبة بهذه الطريقة ليست دائماً كمية زمنية ثابتة.
P وT، وماذا تعني الحروف
تبدأ مدة ISO 8601 بالحرف P (period). تليها مكونات التاريخ، وكل مكون هو رقم متبوع بحرف الوحدة الخاص به: Y للسنوات، وM للأشهر، وW للأسابيع، وD للأيام. يفصل الحرف T جزء التاريخ عن جزء الوقت: H للساعات، وM للدقائق، وS للثواني. كل مكون اختياري؛ تكتب فقط ما تحتاجه. PT15M تعني 15 دقيقة، وP1DT2H تعني يوماً وساعتين، وP3W تعني ثلاثة أسابيع. الحرف T ليس زخرفة: فحرف M يعني أشهراً قبله ودقائق بعده، لذا فإن P1M هو شهر واحد بينما PT1M هي دقيقة واحدة. يمكن للمكون الأخير الموجود أن يحمل كسراً عشرياً، كما في PT0.5S لنصف ثانية. والوحدات لا تنتقل من واحدة إلى أخرى تلقائياً: فـPT90M طريقة صحيحة تماماً لكتابة ساعة ونصف.
أين تصادف هذا التنسيق فعلياً
توجد هذه الصياغة في كل مكان تقريباً دون أن تلاحظها. تُبلغ واجهة برمجة تطبيقات YouTube Data عن طول كل فيديو كمدة ISO 8601 (PT4M13S). يقبل HTML المدد في خاصية datetime لعنصر time. تستخدمها دعوات التقويم أيضاً: يكتب معيار iCalendar (RFC 5545) طول الحدث بالشكل PT1H0M0S، رغم أنه يستبعد السنوات والأشهر من قواعده. تغطي xs:duration في XML Schema الصيغة الكاملة، بل تسمح بعلامة الطرح في البداية للمدد السالبة. تحلل المكتبات القياسية هذا التنسيق مباشرة: تقرأ java.time سلاسل P وT عبر Period.parse وDuration.parse، ويوجد التقسيم نفسه في لغات كثيرة أخرى. إذا كنت تنتج جداول أو تغذيات أو واجهات برمجة تطبيقات قابلة لقراءة الآلة، فهذا التنسيق هو اللغة المشتركة للإجابة عن سؤال "كم من الوقت".
لماذا لا يمثل P1M عدداً ثابتاً من الثواني
PT15M تساوي دائماً 900 ثانية. أما P1M فلا: فالشهر يستمر 28 أو 29 أو 30 أو 31 يوماً حسب المكان الذي يبدأ منه، لذا لا يصبح P1M قيمة محددة إلا بعد ربطه بتاريخ. حتى P1D غير مضمونة أن تكون 24 ساعة. في الاتحاد الأوروبي، تُقدَّم الساعات يوم الأحد 29 مارس 2026، لذا لا يستمر ذلك اليوم التقويمي سوى 23 ساعة: فإضافة P1D (يوم تقويمي واحد) وإضافة PT24H (24 ساعة بالضبط) إلى مساء السبت نفسه يؤديان إلى لحظتين مختلفتين. لهذا السبب يملك java.time نوعين، Period للوحدات التقويمية وDuration للثواني الدقيقة، ولهذا تطلب مكتبات التاريخ تاريخاً مرجعياً قبل تحويل أي مدة. تعامل مع المكونات Y وM وW وD كحساب تقويمي، ومع H وM وS فقط كقيم زمنية ثابتة.
ليست مدة: 20260424174227.0Z
قد تبدو سلسلة مثل 20260424174227.0Z وكأنها تنتمي إلى العائلة نفسها، لكنها في الواقع طابع زمني وليست مدة، وليست ISO 8601 أصلاً. إنها GeneralizedTime، تنسيق من ASN.1، وهو الترميز الذي تستخدمه أدلة LDAP وشهادات X.509. اقرأها كحقول ثابتة العرض: السنة 2026، والشهر 04، واليوم 24، ثم 17:42:27، وجزء عشري اختياري (.0)، وZ التي تعني UTC. تصادفها في خصائص Active Directory مثل whenCreated وwhenChanged، وفي عمليات تصدير LDAP، وداخل الشهادات، حيث يفرض RFC 5280 استخدام GeneralizedTime لتواريخ الصلاحية اعتباراً من عام 2050. العلامة التي تميزها عن الصيغة المضغوطة لـISO 8601 هي غياب الحرف T: فلو كانت بصيغة ISO لكُتبت اللحظة نفسها 20260424T174227Z.
فك تشفير مدة دون قراءة المواصفة
بالنسبة لسلسلة واحدة عابرة، يحلل محوِّل مدة ISO 8601 لدينا أي مدة بصيغة P/T إلى مكوناتها وإجماليها بالثواني، ويعيد بناء السلسلة من الأرقام التي تكتبها. وعندما يكون ما لديك وقتين محددين بدلاً من سلسلة مدة (مثل وردية عمل من 22:00 حتى 06:30)، تعطيك حاسبة مدة الوقت الزمن المنقضي، بما في ذلك الفترات التي تمتد عبر منتصف الليل. تعمل الأداتان بالكامل داخل متصفحك: ما تكتبه لا يغادر جهازك أبداً. وللقراءة السريعة دون أي أداة، يكفي انعكاسان لتغطية معظم الحالات: ابحث عن T لتعرف ما إذا كان M يعني أشهراً أو دقائق، وتذكر أن كل ما يقع على يسار T هو حساب تقويمي، وليس عدداً ثابتاً من الثواني.
الأدوات المذكورة في هذا المقال
الأسئلة الشائعة
هل PT1M مثل P1M؟
لا. يغيّر الحرف M معناه على جانبي الفاصل T: فP1M هو شهر واحد، وPT1M هي دقيقة واحدة. هذا هو أكثر سوء فهم شيوعاً لهذا التنسيق، وقد ظهرت بسببه أخطاء برمجية في واجهات برمجة تطبيقات فعلية. عند الشك، ابحث أولاً عن T: كل ما يسبقها يُحسب بالسنوات والأشهر والأسابيع والأيام؛ وكل ما يليها يُحسب بالساعات والدقائق والثواني. المدة المكتوبة بشكل صحيح لا تحتوي أبداً على وحدة زمنية قبل T أو وحدة تاريخ بعدها.
كيف أكتب 90 دقيقة كمدة ISO 8601؟
كل من PT90M وPT1H30M صحيحة وتصفان الكمية نفسها من الوقت. لا يفرض ISO 8601 على المكونات البقاء ضمن نطاقاتها التقليدية، لذا فإن الدقائق التي تتجاوز 59 أو الساعات التي تتجاوز 23 لا مشكلة فيها. تقبل المحللات كلتا الصيغتين؛ وأي صيغة يصدرها نظام ما يعتمد على ما إذا كان يطبّع القيمة أم لا. إذا كنت تنتج مدداً ليقرأها البشر، فإن PT1H30M أوضح؛ وإذا كنت تقارن المدد في الشيفرة البرمجية، قارن مجموع ثوانيها لا السلاسل نفسها، تحديداً لأن سلسلتين مختلفتين قد تعنيان الشيء نفسه.
ما الفرق بين المدة والفترة الزمنية؟
تحدد المدة مقدار الطول فقط، دون موضع على التقويم: فP3D تعني ثلاثة أيام، تبدأ من أي مكان. تربط الفترة الزمنية في ISO 8601 مدة ما بتواريخ فعلية، وتُكتب بشرطة مائلة: 2026-07-04T00:00:00Z/P3D تعني ثلاثة أيام تبدأ في 4 يوليو 2026، وزوج بداية/نهاية مثل 2026-07-04/2026-07-07 يعبّر عن الامتداد نفسه. توجد أيضاً فترات متكررة بسابقة R: R5/2026-07-04T00:00:00Z/P1D تعني خمسة تكرارات يومية بدءاً من تلك اللحظة. تحل الفترات الزمنية غموض الوحدات التقويمية، لأن P1M المرتبطة بتاريخ محدد يكون لها دائماً طول واحد محدد.