ناشر الأحداث المتكررة

قاعدة التكرار برنامج لا تاريخ

لا تحوي RRULE:FREQ=MONTHLY;BYDAY=-1FR;COUNT=12 تاريخاً واحداً. إنها تحوي تعليمات لإنتاج التواريخ، والطريقة الوحيدة الصادقة للإجابة عن متى يقع هذا فعلاً هي تنفيذ تلك التعليمات. وهذه الأداة تنفّذها.

ما الذي يُطبَّق

كل ما في RFC 5545 §3.3.10: FREQ وINTERVAL وCOUNT وUNTIL وWKST، وأجزاء BY* التسعة بما فيها الترتيبات السالبة مثل -1FR («آخر جمعة»)، وBYSETPOS. وفوق القاعدة، يحذف EXDATE تواريخ ويضيف RDATE أخرى — ويذكر كل سطر من أيهما جاء، لأن تاريخاً موجوداً فقط لأن أحدهم أضافه بيده شيء آخر غير تاريخ ولّدته القاعدة.

لماذا يهم عمود إزاحة UTC

اجتماع أسبوعي في التاسعة صباحاً يبقى في التاسعة عند تغيير الساعة. أما اللحظة فتتزحزح ساعة؛ وقراءة ساعة الحائط لا تتغير. هذا ما يقتضيه RFC 5545، وهذا ما يخطئ فيه أسلوب «أضف ٧ × ٨٦٤٠٠٠٠٠ جزءاً من الألف من الثانية» مرتين كل عام. لذلك يعرض كل تكرار القراءتين جنباً إلى جنب: الوقت المحلي، واللحظة الحقيقية بتوقيت UTC مع الإزاحة التي أنتجتها. وحين تختلف إزاحتان، تقول الأداة ذلك صراحة.

تُحلّ المناطق من قاعدة IANA في متصفحك حين يكون TZID اسم منطقة حقيقياً، ومن كتلة VTIMEZONE داخل الملف فيما عدا ذلك — وهكذا تُحلّ صحيحاً أسماء اخترعتها مايكروسوفت مثل Romance Standard Time. وإذا لم ينفع أيٌّ منهما، تُعرض الإزاحة على أنها غير معروفة بدل افتراضها UTC بصمت.

حدود مذكورة بوضوح

تُنشَر القاعدة اللانهائية حتى السقف الذي تحدده، ويُوسم الناتج بأنه مقتطع. أما قاعدة بقيود مستحيلة — FREQ=YEARLY;BYMONTH=2;BYMONTHDAY=30 قاعدة مشروعة ولا يمكن أن توافق يوماً حقيقياً — فلا تنتج شيئاً، وتقول الأداة لماذا بدل عرض جدول فارغ.

الخصوصية

كل شيء يجري في متصفحك. لا يُرفع أي ملف تقويم ولا يتصل شيء هنا بالشبكة.