تقنية

حدث طوال اليوم يصوغه المساعد: هل تاريخ النهاية يوم مشمول؟

رسم توضيحي: البداية:10 أكتوبر؛ اليوم المشمول:10؛ اليوم المشمول:11؛ النهاية غير المشمولة:12
مخطط من إعداد بحر العلوم. قيم DATE مؤلفة؛12 حد خروج وليس يوما إضافيا

تاريخ نهاية حدث طوال اليوم في iCalendar يحتاج قراءة مختلفة عن عبارة «حتى يوم كذا» في رسالة عادية. إذا نقل المساعد تاريخ DTEND إلى قائمة الأيام المشمولة، فقد أضاف يوما. نقرأ قاعدة VEVENT في RFC 5545 ونراجع تاريخين مؤلفين، دون إنشاء حدث أو استيراد ملف.

الخلاصة السريعة

في VEVENT نهاية DTEND غير شاملة؛ لحدث ذي قيم DATE لا يكون تاريخها نفسه يوما مشمولا، بينما تاريخ DTSTART يدخل بداية الفترة.

  • تنص RFC 5545 على بداية شاملة ونهاية غير شاملة لـVEVENT؛ وإذا كانت البداية DATE وكانت هناك نهاية، فتكون النهاية DATE أيضا. [1]
  • في مثال DATE من 10 أكتوبر 2026 إلى نهاية مخزنة 12 أكتوبر، اليومان المشمولان هما 10 و 11؛ لا نضيف 12 إلى قائمة أيام الحدث.
  • إذا أردنا أن يشمل المثال يوم 12 أيضا، يكون حد النهاية غير الشامل 13؛ لا نستبدله بساعة 23:59 أو نفترض منطقة زمنية من تاريخ بلا ساعة.
  • اقرأ نوع القيمة والحقول الأصلية قبل صياغة الوصف؛ لا تنقل معنى النهاية إلى كل موعد مكتوب، ولا تصف الحساب باستيراد ناجح أو حضور تحقق.

أي نهاية يحددها معيار الحدث؟

تحدد RFC 5545 بداية VEVENT شاملة ونهايته DTEND غير شاملة؛ مع بداية DATE تكون النهاية المذكورة DATE كذلك. [1]

نحصر المقال في قراءة هذا المكون وقيم التاريخ. لا نعمم قاعدة نهاية الملف على لغة رسالة بشرية مثل «العرض حتى 12 أكتوبر»، لأن كاتبها قد يقصد شمول اليوم؛ نحتاج توضيحا قبل تحويلها إلى حقول.

كذلك لا نخلط حدثا بالتاريخ مع مهمة لها موعد تسليم أو اجتماع ذي ساعات. اسم خانة النهاية وحده لا يحسم معنى منتج آخر. نطلب من المساعد الاحتفاظ باسم الحقل ونوعه والقاعدة التي يستند إليها الشرح.

ما اليومان داخل تاريخي مثالنا؟

نؤلف بطاقة حدث طوال اليوم تبدأ في 10 أكتوبر 2026، وحد نهاية مخزن 12 أكتوبر 2026. نفترض أن الحقلين DTSTART وDTEND يحملان DATE. هذه معطيات تمرين وليست مواعيد معرض قائم.

نبدأ عند يوم 10، ونضم 11، ونتوقف قبل 12. إذن الوصف «يشمل 10 و 11 أكتوبر» يطابق المعطيات. أما «يشمل 10 و 11 و 12» فينقل حد النهاية إلى داخل الفترة ويضيف يوما لم تتضمنه القاعدة.

يمكن أن يكتب المساعد «آخر يوم مشمول 11، وحد النهاية المخزن 12». يحفظ هذا الفرق للقارئ الذي يعود إلى البطاقة. لا نغير الرقم في المصدر كي يبدو الوصف المختصر أقل غرابة.

دور التاريخ المؤلفالقيمةهل اليوم مشمول؟
البداية10 أكتوبر 2026نعم
اليوم التالي11 أكتوبر 2026نعم
حد النهاية12 أكتوبر 2026لا

كيف نمثل رغبة شمول يوم إضافي؟

نفترض طلبا مختلفا واضحا يقول إن أيام العرض المطلوبة 10 و 11 و 12. لكي يطابقها حد النهاية غير الشامل في مثال DATE، نضع 13 أكتوبر، مع بقاء البداية 10. هذه مراجعة معطيات مقترحة، وليست تعديل حدث نفذناه.

ولا نكتب 12 أكتوبر الساعة 23:59 بدلا من التاريخ 13. لم يعطنا المثال ساعة أو نوع DATE-TIME؛ تغيير النوع يضيف قرارا مختلفا. لا نستنتج منطقة زمنية أو عدد ساعات فعلية من بطاقة تاريخ لا تحمل ساعات.

إذا كان الطلب البشري غامضا عن شمول 12، نسأل عن الأيام المقصودة بدلا من اختيار تفسير مريح. قد يكون الملف صحيحا والوصف البشري مختلفا، أو العكس؛ لا نحدد السبب من رقم النهاية وحده.

ماذا ينبغي أن يظهر في نتيجة المراجعة؟

نقترح ورقة تسجل البداية والنهاية المخزنة ونوع القيمة وآخر يوم مشمول بحسب القاعدة. نربطها بالحدث المقصود دون نقل تاريخ من حدث آخر أو دمج سلسلة متكررة لا يناقشها المثال.

عند غياب الحقول الأصلية، لا نزعم أننا قرأنا VEVENT من صورة عنوان تقويم. وعند وجودها، صحة تفسير اليومين لا تثبت أن برنامج المستلم عرضهما كما أردنا؛ العرض الفعلي يحتاج فحصا مستقلا إذا جرى الاستيراد.

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

المصادر ومتابعة القراءة

  1. RFC 5545: 3.6.1 Event Component (يفتح في نافذة جديدة)rfc-editor.org

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.