الإصدار: Discourse 2026.1.5 (ESR)، إضافة discourse-calendar
ملخص
تظهر الأحداث الجديدة التي تم إنشاؤها بـ منطقة زمنية محددة (timezone="Europe/Berlin" و showLocalTime="true") وقتاً خاطئاً بزيادة +1 ساعة عند تنزيل ملف .ics واستيراده في Outlook (Windows). الوقت صحيح داخل المنتدى نفسه. تتأثر الأحداث الجديدة فقط، أي الاستيراد عبر ملف .ics.
إعادة إنتاج المشكلة
إنشاء حدث (اليوم، في وقت التوقيت الصيفي CEST/UTC+2): 5:00 مساءً – 7:15 مساءً بتوقيت برلين.
(لا يحتوي الملف على كتلة VTIMEZONE لـ Europe/Berlin.)
التحليل / السبب المشتبه به
يحدد التصدير الوقت محلياً باستخدام TZID=Europe/Berlin (اسم IANA) بدلاً من التوقيت العالمي المنسق (...Z). لا يفهم Outlook أسماء المناطق الزمنية من IANA (فهو يستخدم معرفات Windows مثل “W. Europe Standard Time”)، وغياب تعريف VTIMEZONE يجعله يعتمد على الإزاحة الثابتة UTC+1 (CET/الوقت الشتوي). خلال الوقت الصيفي (CEST = UTC+2) يؤدي هذا إلى زيادة +1 ساعة بالضبط. التحقق المتقاطع: استيراد نفس الملف إلى Google Calendar (الذي يفهم مناطق IANA بشكل أصلي) يعرض الوقت الصحيح 17:00.
اقتراح: يجب أن يستخدم تصدير ICS إما طوابع زمنية بالتوقيت العالمي المنسق مع Z أو يولد كتلة VTIMEZONE كاملة تتضمن قواعد التوقيت الصيفي (انظر أيضاً النقاش حول الامتثال لمواصفات ICS في الموقع غير متاح في تصدير ICS الكامل).
ملاحظة إضافية: عند إنشاء نفس الحدث بدونtimezone=/showLocalTime، يستخدم ملف .ics المُصدّر التوقيت العالمي المنسق ويظهر Outlook +2 ساعات (بما أن 17:00 بالتوقيت العالمي = 19:00 بتوقيت CEST). هذا هو السلوك الموثق للتوقيت العالمي المنسق، لكنه يوضح أيضاً أن التعامل مع المناطق الزمنية حول تصدير ICS محير للمستخدمين الذين يتوقعون أوقاتاً محلية.
للمقارنة، كنت أقوم بتشغيل مضيف Discourse وحاوية التطبيق في المنطقة الزمنية المحلية المعتمدة من IANA بدلاً من UTC بسبب سلوك المنطقة الزمنية للتقويم في السابق.
أكون مهتمًا بمعرفة ما إذا كان ذلك يغير استيراد حدث برلين الساعة 17:00 من الاستيراد في الساعة 18:00 إلى الساعة 17:00 المتوقعة.
إذا كان الأمر كذلك، فإن ذلك يشير إلى أن المنطقة الزمنية لـ Discourse/الحاوية تؤثر على التصدير؛ وإذا لم يكن الأمر كذلك، فمن المرجح أن المشكلة المتعلقة بـ VTIMEZONE/التعامل مع Outlook تكون مستقلة عن المنطقة الزمنية للخادم.
تم إنشاء الحدث مع timezone="Europe/Berlin" و showLocalTime="true"، خلال فترة التوقيت الصيفي (CEST).
تم تنزيل ملف .ics عبر خيار “إضافة إلى التقويم” واستيراده في Outlook.
النتيجة الفعلية: يظهر الحدث بتوقيت خاطئ بمقدار +1 ساعة (على سبيل المثال، يظهر وقت 17:00 بتوقيت برلين على أنه 18:00 في Outlook). النتيجة المتوقعة: يجب أن يظهر الحدث في الساعة 17:00 كما تم إدخاله.
يمكننا تأكيد أن هذه المشكلة تحدث باستمرار، وليست متقطعة، للأحداث التي تقع خلال فترة التوقيت الصيفي. الأحداث الأخرى خارج هذه الفترة غير متأثرة.
سنكون سعداء جدًا برؤية إصلاح لهذه المشكلة، حيث يمكن أن يكون مستخدمونا حساسين جدًا تجاه الأعطال
لقد قمت بالتحقيق في الأمر بشكل أعمق وفتحت طلب سحب (PR) لمعالجته:
المشكلة تكمن في تصدير ICS وليس في المنطقة الزمنية للخادم/الحاوية. يستخدم الحدث المُصدَّر معرّف TZID من IANA مثل Europe/Berlin، لكنه حاليًا لا يتضمن تعريف VTIMEZONE المقابل الذي تحتاجه العملاء مثل Outlook لتفسير قواعد التوقيت الصيفي بشكل موثوق.
يضيف طلب السحب تعريفات VTIMEZONE إلى تنزيلات ICS التي تأخذ المنطقة الزمنية في الاعتبار، مع الإبقاء على قيم DTSTART/DTEND المحلية الحالية.
بالنسبة للمثال المذكور في هذا الموضوع، أصبح التصدير يتضمن أحكام CET/CEST الخاصة بـ Europe/Berlin، وبالتالي:
DTSTART;TZID=Europe/Berlin:20260811T170000
يمكن تفسيره مع إزاحة الصيف الصحيحة UTC+2 بدلاً من لجوء Outlook إلى UTC+1.
كما أضفت تغطية لقواعد التوقيت الصيفي في أوروبا وأمريكا الشمالية، وحالة الإزاحة الثابتة، وانتقالات المواسم الأكثر غرابة المستخدمة في Africa/Casablanca.
