همهٔ تاریخهای یک تکرار، پیش از آنکه به تقویم شما برسند
تکرار روزانه، هفتگی، ماهانه یا سالانه را به تاریخهای واقعی بسط میدهد، قاعدهٔ تاریخ گمشده را صریح میکند و برای هر رخداد یک رویداد تقویمی تمامروز مبتنی بر استاندارد صادر میکند.
تقویم
برای هر سطر یک VEVENT تمامروز مطابق استاندارد، با مقدار DTEND انحصاریِ روز بعد و شناسههای پایدار رویداد.
همهٔ تاریخهای برنامه
| ۱ | 2026-08-01 | شنبه | ۰ | تاریخ مبنا |
| ۲ | 2026-08-15 | شنبه | ۱۴ | دقیقاً روز مبنا |
| ۳ | 2026-08-29 | شنبه | ۲۸ | دقیقاً روز مبنا |
| ۴ | 2026-09-12 | شنبه | ۴۲ | دقیقاً روز مبنا |
| ۵ | 2026-09-26 | شنبه | ۵۶ | دقیقاً روز مبنا |
| ۶ | 2026-10-10 | شنبه | ۷۰ | دقیقاً روز مبنا |
| ۷ | 2026-10-24 | شنبه | ۸۴ | دقیقاً روز مبنا |
| ۸ | 2026-11-07 | شنبه | ۹۸ | دقیقاً روز مبنا |
| ۹ | 2026-11-21 | شنبه | ۱۱۲ | دقیقاً روز مبنا |
| ۱۰ | 2026-12-05 | شنبه | ۱۲۶ | دقیقاً روز مبنا |
| ۱۱ | 2026-12-19 | شنبه | ۱۴۰ | دقیقاً روز مبنا |
| ۱۲ | 2027-01-02 | شنبه | ۱۵۴ | دقیقاً روز مبنا |
چگونگی کار
این ابزار چه چیزی را محاسبه میکند
«هر ماه» هر وقت تاریخ اول ۲۹ام، ۳۰ام یا ۳۱ام باشد ناقص است. فوریه ممکن است آن را نداشته باشد؛ بعضی ماههای دیگر ۳۱ام ندارند؛ و ۲۹ فوریهٔ سالانه فقط در سالهای کبیسه وجود دارد. یک برنامه باید بگوید تاریخ گمشده جابهجا میشود یا ناپدید میشود.
این ابزار آن تصمیم را پیش از وارد کردن هر چیزی به تقویم بسط میدهد. هر سطر قابل مشاهده است، بهصورت CSV دانلود میشود و همچنین در یک فایل iCalendar بهصورت یک رویداد تمامروز مستقل نوشته میشود. هیچ قاعدهٔ تکرار پنهانی وجود ندارد که نرمافزار دیگری بتواند آن را متفاوت تفسیر کند.
روش
روزها و هفتهها گامهای ثابتی از روزهای تقویمی هستند. دو هفته چهارده روز است، بنابراین روز هفته نمیتواند تغییر کند. تاریخ اول خودش سطر یک است، یعنی دوازده تاریخ دوهفتگی یازده فاصله دارند و ۱۵۴ روز را در بر میگیرند.
ماهها و سالها بهجای آن از یک مبنا استفاده میکنند. برای سطر n، ماه یا سال مقصد از تاریخ اصلی و فاصلهٔ درخواستی پیدا میشود. سپس اگر روز اصلی در آن وجود داشته باشد همانجا گذاشته میشود. اگر نه، حالت پایان ماه آخرین روز موجود را برمیدارد و حالت رد کردن به نامزد بعدی میرود.
پیش از ادامهٔ مطلب
یک برنامهٔ ماهانه از ۳۱ ژانویه ۲۰۲۶ شروع میشود و برای تاریخهای گمشده از پایان ماه استفاده میکند. رخداد مارس چیست؟
۳۱ مارس. ۲۸ فوریه جایگزینی موضعی برای ۳۱امِ گمشده است، نه یک مبنای جدید. مشتق کردن مستقیم مارس از تاریخ اصلی ۳۱ ژانویه نمیگذارد یک ماه کوتاه همهٔ رخدادهای بعدی را جابهجا کند.
یک نمونه کار شده
از شنبه ۱ اوت ۲۰۲۶ شروع کنید، هر دو هفته یک بار تکرار کنید و دوازده تاریخ بخواهید:
| رخداد | تاریخ | روز هفته | روز از شروع |
|---|---|---|---|
| ۱ | ۲۰۲۶-۰۸-۰۱ | شنبه | ۰ |
| ۲ | ۲۰۲۶-۰۸-۱۵ | شنبه | ۱۴ |
| ۳ | ۲۰۲۶-۰۸-۲۹ | شنبه | ۲۸ |
| ۴ | ۲۰۲۶-۰۹-۱۲ | شنبه | ۴۲ |
| ۱۲ | ۲۰۲۷-۰۱-۰۲ | شنبه | ۱۵۴ |
برای برنامهٔ ماهانهای با مبنای ۳۱ ژانویه ۲۰۲۶، حالت پایان ماه با ۳۱ ژانویه، ۲۸ فوریه، ۳۱ مارس و ۳۰ آوریل شروع میشود. دو تا از آن چهار تاریخ اول بهعنوان «منتقلشده به پایان ماه» گزارش میشوند. حالت رد کردن در عوض با ۳۱ ژانویه، ۳۱ مارس، ۳۱ مه و ۳۱ ژوئیه شروع میشود و جدول میگوید هر سطر پذیرفتهشده پس از یک تاریخ گمشدهٔ ردشده آمده است. هر دو دنباله و ارقام دوهفتگی در آزمونهای فرمول تثبیت شدهاند.
فایل تقویم حاوی چه چیزی است
هر سطر به یک VEVENT تمامروز تبدیل میشود. DTSTART آن تاریخ فشرده و DTEND انحصاری آن روز بعد است. عنوانی که وارد میکنید برای بکاسلش، کاما، نقطهویرگول و شکست خط گریز داده میشود؛ خطوط بلندتر از ۷۵ اکتت UTF-۸ با فاصلهٔ ادامهٔ الزامی تا میشوند؛ و شناسههای پایدار یعنی وارد کردن نسخهای دوبارهساختهشده میتواند بهعنوان همان مجموعه رویدادها شناخته شود.
مُهر زمانی تولید تنها مقدار «اکنون» در فایل است. برنامه را تغییر نمیدهد و در URL صفحه قرار نمیگیرد یا به جای دیگری فرستاده نمیشود.
مراحل انجام کار
- تاریخ اول بهعنوان مبنای تقویم میلادی خوانده میشود، سپس پیش از ساختن برنامه، فاصله و تعداد رخدادهای درخواستی به بازهٔ مجاز محدود میشوند.
- برای روزها و هفتهها، تعداد ثابتی روز تقویمی UTC اضافه میشود. برای ماهها و سالها، هر نامزد از سال، ماه و روز اصلی مشتق میشود، نه از نتیجهٔ قبلی.
- اگر ماه نامزد روز مبنا را نداشته باشد، دقیقاً مطابق انتخاب شما، یا از آخرین روز آن استفاده میشود یا آن نامزد کنار گذاشته میشود. این کار تا رسیدن به تعداد تاریخهای واقعی درخواستی ادامه مییابد.
- سطرها بهصورت مؤلفههای جداگانهٔ VEVENT تمامروز طبق RFC ۵۵۴۵ نوشته میشوند. DTSTART خود تاریخ است، DTEND تاریخ بعدی است چون پایان رویداد تمامروز انحصاری است، و هر خط محتوا در ۷۵ اکتت UTF-۸ تا میشود.
فرضها
- تقویم میلادی و فقط تاریخ است. هیچ ساعتی از روز، منطقهٔ زمانی، تغییر ساعت تابستانی یا یادآوریای برای استنباط وجود ندارد.
- تاریخ اول رخداد شمارهٔ یک است. بنابراین دوازده تاریخ یازده فاصله دارد، نه دوازده.
- حالت پایان ماه هرگز مبنا را تغییر نمیدهد. ۳۱ ژانویه میتواند ۲۸ فوریه شود و سپس به ۳۱ مارس برگردد، چون هر نامزد از روز اصلی ۳۱ مشتق میشود.
- حالت رد کردن یک نامزد گمشده را رد میکند، نه یک فاصله را. در ماهها یا سالهای نامزد بعدی ادامه میدهد تا تعداد تاریخهای واقعی درخواستی فراهم شود.
- سالهای تقویمی بالاتر از ۹۹۹۹ را نمیتوان با مقدار DATE چهاررقمی RFC ۵۵۴۵ نشان داد و تولید نمیشوند.
پرسشهای رایج
آیا هر ماه تاریخ تکرار ماهانه را دارد؟
فقط مبناهای اول تا بیستوهشتم در هر ماه وجود دارند. بیستونهم، سیام و سیویکم برای ماههای کوتاهتر به یک قاعده نیاز دارند؛ به همین دلیل ابزار بهجای حدس زدنِ بیصدا میپرسد.
چرا پایان رویداد تمامروز تقویم روی تاریخ بعدی گذاشته میشود؟
RFC ۵۵۴۵ DTEND را مرزی غیرشامل تعریف میکند. رویدادی که فقط ۱ اوت را میپوشاند از ۱ اوت شروع میشود و در آغاز ۲ اوت تمام میشود؛ استفاده از یک تاریخ برای هر دو، رویدادی با طول صفر میسازد.
آیا ساعت تابستانی روی تکرارهای هفتگی اثر میگذارد؟
اینها سطرهای فقطتاریخ هستند، نه لحظههایی در زمان. اضافه کردن هفت روز تقویمی روز هفته را حفظ میکند و ساعتی در کار نیست که آفست UTC آن تغییر کند.
آیا وارد کردن فایل یک رویداد تکرارشونده میسازد یا چندین رویداد؟
برای هر سطر قابل مشاهده یک VEVENT تمامروز میسازد. این کار برنامهٔ بسطیافتهٔ دقیق را، از جمله تعدیلهای پایان ماه و تاریخهای ردشده، بدون اتکا به تفسیر هر نرمافزار تقویم از قواعد تکرار حفظ میکند.