«هر ۲۴ ساعت» با «هر روز ساعت ۹» یکی نیست

مسئول عملیات از دستیار می‌خواهد گزارش را هر روز ساعت ۹ صبح برای دفتر نیویورک بفرستد. دستیار اولین نوبت را درست می‌سازد و برای نوبت بعد، ۲۴ ساعت به آن اضافه می‌کند. چند هفته همه‌چیز درست به نظر می‌رسد؛ روز تغییر ساعت رسمی، گزارش ساعت ۱۰ می‌رسد. مدل جمله را فهمیده، ولی سامانه معنای «هر روز» را هنگام ذخیره‌کردن از دست داده است.

این موقعیت آموزشی، گزارش خرابی یک محصول مشخص نیست. مسئله‌اش برای هر دستیارِ سازنده یادآوری، برنامه ارسال یا کار زمان‌بندی‌شده مطرح است: کاربر می‌خواهد فاصله اجراها ثابت بماند یا ساعت روی دیوار؟ پیش از انتخاب ابزار و نوشتن دستور زمان‌بندی، باید همین تصمیم را ثبت کرد. تبدیل همه‌چیز به UTC، پاسخ این سؤال نیست.

نخست معلوم کنید چه چیزی باید ثابت بماند

«فردا ساعت ۹»، «هر روز ساعت ۹» و «۲۴ ساعت بعد» درخواست‌های یکسانی نیستند. پیشنهاد ژرف این است که رابط ساخت برنامه، چهار نوع را جدا بگیرد. این دسته‌بندی و معیارهای اجرایی مقاله، تحلیل ما هستند؛ الزام یک استاندارد یا قابلیت تأییدشده همه محصولات نیستند.

برای یک بررسی فنیِ دوره‌ای، فاصله ثابت شاید انتخاب درست باشد. برای گزارش ابتدای شیفت، معمولاً ساعت محلی دفتر اهمیت دارد. این را از نام کار حدس نزنید. حتی عبارت «هر روز» ممکن است منظورش روز کاریِ شعبه باشد، نه تمام روزهای هفته. تعطیلات و آخرین روز کاری ماه نیز به تقویم کاری مشخص احتیاج دارند؛ نام منطقه زمانی چنین فهرستی را در خود ندارد.

موعد بدون ساعت را هم خودسرانه به نیمه‌شب تبدیل نکنید. آن تبدیل، یک تصمیم تازه درباره مرز روز و محل آن وارد می‌کند. استاندارد iCalendar مقدار تاریخ را از تاریخ‌وساعت جدا می‌کند و برای تکرار، اجزایی مانند شروع و قاعده تکرار دارد. داشتن رشته‌ای با ظاهر تاریخ، به‌تنهایی نوع درست درخواست را تعیین نمی‌کند.

دو صبح پیاپی همیشه ۲۴ ساعت فاصله ندارند

مثال نیویورک را می‌توان بدون مدل زبانی حساب کرد. با قواعد منطقه America/New_York، ساعت ۹ روز ۷ مارس ۲۰۲۶ برابر ۱۴ به وقت UTC است. صبح بعد، ساعت ۹ برابر ۱۳ به وقت UTC می‌شود. دو نوبت محلی درست، فقط ۲۳ ساعت فاصله دارند.

این محاسبات را برای مقاله با کتابخانه استاندارد پایتون و داده زمانی نصب‌شده اجرا کردیم؛ آزمون یک سامانه زمان‌بندی کامل نیستند. نتیجه نشان می‌دهد چرا موفقیت اولین اجرا کافی نیست. اگر آزمون پذیرش فقط «نوبت فردا درست است» باشد، خطا ممکن است تا تغییر بعدی ساعت پنهان بماند. نمونه‌های آزمون باید از مرز تغییر عبور کنند، نه اینکه فقط چند روز عادی نزدیک به هم باشند.

اختلاف با UTC، مثل -05:00، وضعیت همان لحظه را می‌گوید. نام منطقه، قواعد تبدیل زمان‌های دیگر را نیز مشخص می‌کند. RFC 9557 این تفاوت را توضیح می‌دهد و یادآور می‌شود که قواعد نام یک منطقه ممکن است تغییر کنند. بنابراین برای برنامه روزانه، نامی مثل America/New_York را با اختلاف امروز جایگزین نکنید.

برای نمونه تهران نیز ساعت ۹ روز ۲۸ سپتامبر ۲۰۲۶، با داده نصب‌شده ما، برابر ۰۵:۳۰ UTC است. این برابریِ یک روز، مجوز حذف Asia/Tehran از برنامه آینده نیست. اگر قرار کاربر با ساعت محلی تهران است، همان قصد باید در داده باقی بماند؛ اگر عمداً ۰۵:۳۰ UTC را می‌خواهد، نوع درخواست دیگری ثبت می‌شود.

اگر ساعت موردنظر نرسید یا دو بار رسید، چه کنیم؟

در نیویورک، ساعت ۰۲:۳۰ روز ۸ مارس ۲۰۲۶ هنگام جلوکشیدن ساعت وجود ندارد. در اول نوامبر همان سال، ۰۱:۳۰ دو بار رخ می‌دهد: یک بار در ۰۵:۳۰ UTC و بار دیگر در ۰۶:۳۰ UTC. پرسش «این زمان را تبدیل کن» در حالت اول پاسخ ندارد و در حالت دوم دو پاسخ دارد. هیچ قالب زیباتری برای نمایش تاریخ، این تصمیم را حذف نمی‌کند.

صاحب کار باید از قبل انتخاب کند. برای نوبت ناموجود، ردکردن نوبت یا انتقال آن به زمان معتبرِ تعریف‌شده دو سیاست متفاوت‌اند. «به جلو منتقل کن» هم کافی نیست: اولین لحظه معتبر بعدی را می‌خواهید یا حفظ دقیقه با افزودن اندازه جهش؟ برای ساعت تکراری، اجرای اول، اجرای دوم یا هر دو نتایج متفاوتی دارند. انتقال یا دو بار اجراکردن را پیش‌فرض خاموش سامانه نگذارید.

مستندات zoneinfo پایتون انتخاب دو سوی ساعت تکراری را با fold توضیح می‌دهد. این امکان کتابخانه، سیاست کسب‌وکار را انتخاب نمی‌کند. سازنده برنامه باید انتخاب را صریح ثبت کند و آزمون، تبدیل رفت‌وبرگشت را بررسی کند. صرف اینکه برنامه توانسته شیء تاریخ‌وساعت بسازد، دلیل معتبر بودن ساعت محلی نیست.

همه موتورهای اجرا را هم یکسان فرض نکنید. راهنمای Cloud Scheduler درباره ناهنجاری اجرا در تغییر ساعت دیواری هشدار می‌دهد و برای آهنگ زمانی مشخص، UTC را پیشنهاد می‌کند. این راه‌حل برای فاصله ثابت مفید است؛ ولی خواسته «همیشه ۹ صبح دفتر» را به‌خودی‌خود حفظ نمی‌کند. هنگام انتخاب موتور، رفتار واقعی آن را با سیاست مصوب مقایسه کنید.

مدل پیشنهاد بدهد؛ کتابخانه زمان‌ها را حساب کند

از مدل بخواهید جمله کاربر را به یک پیشنهاد ساخت‌یافته تبدیل کند، نه اینکه زمان صد اجرای آینده را از حافظه بسازد. برای گزارش روزانه، پیشنهاد دست‌کم شامل نوع تکرار، ساعت محلی، نام منطقه، تاریخ شروع، پایان یا تعداد نوبت‌ها و سیاست ساعت ناموجود و تکراری باشد. متن اصلی و زمینه‌ای را هم که «فردا» بر اساس آن فهمیده شده، برای بازبینی نگه دارید.

سرویس قطعیِ محاسبه زمان سپس نام منطقه و تاریخ را اعتبارسنجی می‌کند، نوبت‌های محلی را می‌سازد و هرکدام را به لحظه اجرا تبدیل می‌کند. خروجی آن باید زمان محلی، اختلاف با UTC، لحظه UTC و دلیل هر حذف یا جابه‌جایی را داشته باشد. اگر برای یک ورودی دو جواب معتبر پیدا کرد و سیاستی وجود نداشت، برنامه هنوز آماده فعال‌شدن نیست. مقدار مجهول را با منطقه زمانی سرور پُر نکنید.

یک قرارداد ساده آموزشی برای «گزارش روزانه» چنین اطلاعاتی دارد:

• ساعت ۹، هر روز، در America/New_York؛ نه منطقه مرورگر و نه منطقه سرور.
• شروع از تاریخ تأییدشده؛ پایان یا بازبینی در تاریخ معین.
• نوبت ناموجود: حذف با ثبت علت؛ ساعت تکراری: فقط نخستین رخداد، اگر صاحب کار پذیرفته باشد.
• دیررسیدن: حداکثر ۱۵ دقیقه؛ پس از آن ثبت نوبت ازدست‌رفته، بدون ارسال خودکار گزارش کهنه.
• عملیات و گیرنده ثابت و نسخه‌دار؛ تغییرشان به معنای پیشنهاد تازه است.

عدد ۱۵ دقیقه و سیاست‌های بالا صرفاً انتخاب‌های مثال‌اند، نه توصیه همگانی. یادآوری کم‌خطر، گزارش مدیریتی و دستور حساس الزاماً تحمل یکسان ندارند. این قرارداد همچنین تضمین تحویل دقیق سر ساعت نیست؛ شلوغی صف و خرابی شبکه می‌توانند اجرا را عقب بیندازند. زمان مقرر را از زمان شروع و پایان واقعی جدا ثبت کنید.

بعد از تأیید، لازم نیست مدل در هر اجرا دوباره جمله کاربر را تفسیر کند. قاعده تکرار را محاسبه‌گر قطعی اجرا کند. مدل، در محدوده مجاز، محتوای گزارش را بسازد؛ تولید محتوا به معنای اجازه تغییر برنامه‌ای نیست که آن را فراخوانده است. جداکردن این دو نقش، بازبینی رفتار را هم ساده‌تر می‌کند.

تأیید کاربر باید چند نوبت واقعی را نشان بدهد

به‌جای دکمه‌ای زیر جمله «برنامه ساخته شد»، خلاصه‌ای قابل بررسی نشان دهید: نوع تکرار، منطقه، تقویم، ساعت و چند تاریخ آینده. نمونه‌ها را طوری انتخاب کنید که نزدیک‌ترین تغییر اختلاف زمانی را هم پوشش دهند. اگر در افق برنامه تغییری نیست، این موضوع را روشن بنویسید؛ لازم نیست یک تغییر خیالی بسازید. کنار زمان دفتر، نمایش زمان بیننده مفید است، به شرط اینکه این دو برچسب واضح داشته باشند.

برای کاربر فارسی‌زبان، «اول هر ماه» سؤال دیگری هم دارد: ماه کدام تقویم؟ تغییر شکل رقم‌ها، تبدیل تقویم نیست. اگر ماه شمسی مقصود است، موتور باید تکرار در همان تقویم را پشتیبانی کند؛ تبدیل اولین تاریخ به میلادی و تکرار ماهانه آن، همان برنامه نیست. تبدیل با کتابخانه آزموده انجام شود و نام ماه، سال و روز هفته در تأیید دیده شود. در صورت پشتیبانی‌نشدن، محدودیت را بگویید.

برای «فردا صبح» نیز زمان دریافت درخواست و منطقه مبنای «فردا» را تثبیت کنید. اگر پردازش از نیمه‌شب عبور کرد، مدل دوم نباید تاریخ تازه‌ای انتخاب کند. تأیید به نسخه مشخص پیشنهاد متصل باشد. راهنمای تأیید انسانی همین اصل را برای پارامترهای عملیات توضیح می‌دهد: تغییر ساعت، منطقه، گیرنده یا سیاست تکرار، تأیید قبلی را بی‌اعتبار می‌کند.

تغییر قواعد ساعت، تغییر برنامه کاربر نیست

پایگاه زمانی IANA قواعد را برای تغییر تصمیم‌های رسمی درباره ساعت و مرز مناطق به‌روز می‌کند. در روز بررسی این مقاله، نسخه تازه نمایش‌داده‌شده ۲۰۲۶d بود، با تاریخ انتشار ۱۱ سپتامبر. تازه‌بودن وب‌سایت به معنی تازه‌بودن داده روی همه سرورهای شما نیست. نسخه داده محاسبه‌گر و اجراکننده را جدا ثبت و مقایسه کنید.

پیشنهاد ما این است که پس از به‌روزرسانی، نوبت‌های آینده هنوز اجرا‌نشده را دوباره محاسبه کنید و تفاوت را به صاحب برنامه نشان دهید. آیا قرار است ساعت محلی ثابت بماند یا لحظه‌ای که قبلاً با طرف دیگر توافق شده؟ برای برنامه روزانه معمولاً اولی و برای تعهد تثبیت‌شده شاید دومی مهم‌تر باشد؛ تصمیم را از نوع درخواست و تأیید ثبت‌شده بگیرید. سوابق اجراهای گذشته را بازنویسی نکنید.

فقط ذخیره هزار زمان UTC برای آینده، تغییر قواعد را پرهزینه می‌کند. نگهداری قاعده اصلی همراه با افق محدودی از نوبت‌های حل‌شده، امکان بازبینی می‌دهد. ثبت نسخه داده نیز برای توضیح اینکه چرا دیروز محاسبه دیگری داشتیم مفید است. این مسئله با زمان رخداد و نسخه حقیقت ارتباط دارد، ولی سؤال اینجا تعهد آینده است، نه اینکه یک واقعیت گذشته چه زمانی معتبر بوده است.

نوبت ازدست‌رفته را با تلاش دوباره اشتباه نگیرید

فرض کنید اجراکننده تا ساعت ۱۱ خاموش بوده است. دو تصمیم جدا دارید: آیا نوبت ساعت ۹ هنوز ارزش اجرا دارد، و اگر قبلاً اثرش ثبت شده باشد چطور دوباره اجرا نشود؟ حذف، اجرای آخرین نوبت یا جبران همه نوبت‌ها گزینه‌های متفاوت‌اند. جبران همه را بدون سقف تعداد و عمر فعال نکنید؛ بازگشت سرویس نباید موج ارسال‌های کهنه بسازد.

هر نوبت منطقی، شناسه‌ای پایدار داشته باشد که به برنامه، نسخه آن و نوبت محلی تعلق دارد؛ اگر هر دو رخداد ساعت تکراری مجازند، تمایزشان هم در شناسه بیاید. تلاش‌های مجدد همان شناسه را حفظ کنند. ساعت واقعی بیدارشدن کارگر، شناسه نوبت نیست. راهنمای تلاش مجدد بدون اثر تکراری جزئیات مرز ثبت اثر را توضیح می‌دهد؛ داشتن زمان درست، به‌تنهایی مانع ارسال دوباره نمی‌شود.

ویرایش برنامه نیز به رسیدگی به صف نیاز دارد. کارگر پیش از اثر بیرونی، معتبر بودن نسخه و مجوز را بررسی کند. اگر کاربر ساعت را عوض کرده، نوبت آماده‌شده نسخه قبلی نباید فقط به دلیل حضور در صف اجرا شود. رابطه نوبت لغوشده و جایگزینش را نگه دارید تا تغییر منطقه یا به‌روزرسانی قواعد، همان کار تجاری را با دو شناسه تازه تکرار نکند.

پیش از فعال‌سازی، موارد مرزی را امتحان کنید

مجموعه آزمون باید علاوه بر روز عادی، جهش به جلو، ساعت تکراری، انتهای ماه، سال کبیسه، ورودی بدون منطقه و خاموشی طولانی را داشته باشد. برای مثال‌های این مقاله، انتظار روشن است: دو صبح مارس ۲۳ ساعت فاصله دارند؛ ۰۲:۳۰ ناموجود پاسخ معتبر ندارد؛ و ۰۱:۳۰ نوامبر دو لحظه متمایز دارد که فقط سیاست مصوب انتخابشان می‌کند. آزمون باید نتیجه و علت تصمیم را بررسی کند.

در بازپخش صف، دو تلاش برای یک نوبت نباید دو اثر بیرونی بسازند. در تغییر نسخه، نوبت قدیمی باید رد یا به جایگزین مشخص متصل شود. یک تغییر ساختگی در قواعد منطقه نیز آزمون کنید: محاسبه آینده عوض شود، اختلاف قابل مشاهده بماند و تاریخچه گذشته دست‌نخورده باشد. این آزمون ساختگی، آزمون تصمیم محصول است؛ ادعای پیش‌بینی تغییر قانون ساعت نیست.

پس از انتشار قابلیت، تعداد نوبت‌های مقرر، اجراشده در بازه مجاز، حذف‌شده با علت، ازدست‌رفته و دارای اثر تکراری را جدا گزارش کنید. میانگین تأخیر به‌تنهایی نشان نمی‌دهد چند نوبت هرگز ساخته نشده‌اند. نمونه‌ای از زمان محلیِ تأییدشده را با زمان محلیِ تحویل تطبیق دهید. هر تغییر کتابخانه، داده زمانی، منطقه یا قاعده تقویم، دلیل تکرار این بررسی است. سؤال نهایی همان سؤال اول است: کدام بخش وعده کاربر باید ثابت می‌ماند؟

یادداشت منابع — بررسی‌شده در ۲۸ سپتامبر ۲۰۲۶

جدول‌ها، قرارداد، سیاست‌ها و آزمون‌های پذیرش، پیشنهاد ژرف هستند. تبدیل‌های عددی با Python 3.9.6 و داده سیستمی 2026c.1.0 اجرا شدند؛ این داده را با تازه‌ترین نسخه صفحه IANA یکسان فرض نکرده‌ایم. هیچ محصول زمان‌بندی یا مسیر ارسال واقعی در این مقاله ارزیابی نشده است. پیش از کاربرد، رفتار کتابخانه و موتور خودتان را بررسی کنید.

• RFC 9557، اطلاعات تکمیلی زمان — آوریل ۲۰۲۴؛ تفاوت اختلاف زمانی و منطقه نام‌دار.
• RFC 5545، iCalendar — سپتامبر ۲۰۰۹؛ انواع تاریخ و اجزای تکرار، نه تضمین رفتار یک محصول.
• IANA، پایگاه مناطق زمانی — صفحه جاری؛ نسخه ۲۰۲۶d با تاریخ ۱۱ سپتامبر ۲۰۲۶ هنگام بررسی نمایش داده می‌شد.
• Python 3.14، مستندات zoneinfo — مستندات جاری مشاهده‌شده در تاریخ بررسی؛ منابع داده و انتخاب دو رخداد ساعت تکراری.
• Google Cloud Scheduler، قالب کار و منطقه زمانی — آخرین به‌روزرسانی درج‌شده ۲۴ سپتامبر ۲۰۲۶؛ هشدار ساعت دیواری و تغییر ساعت رسمی.