تاريخ نهاية حدث طوال اليوم في 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 أو نرسل دعوة أو نجرب تقويما. يفصل المثال تاريخا مخزنا عن يوم شملته الفترة، كي لا تتحول صياغة المساعد إلى توسيع موعد أو خبر عن مشاركة حصلت.
المصادر ومتابعة القراءة
- RFC 5545: 3.6.1 Event Component (يفتح في نافذة جديدة)rfc-editor.org
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.
