یک تبدیلگر تاریخ شمسی که «امروز» را همیشه درست نشان میدهد، میتواند در ۱۰٪ تاریخهای سال کاملاً غلط باشد — و هیچکس متوجه نشود، چون همان ۱۰٪ (سه ماه پایانی سال شمسی) دقیقاً جایی است که کمتر کسی بهصورت دستی چک میکند.
چرا سه ماه پایانی سال، نقطهی شکست رایج است؟
الگوریتم تبدیل شمسی به میلادی معمولاً اول اختلاف سال را کم میکند، بعد چک میکند سال کبیسه است یا نه. اگر ترتیب برعکس باشد — یعنی کبیسهبودن بعد از کمکردن سال چک شود — نتیجه برای دی، بهمن و اسفند (دقیقاً پایان سال مالی) یک روز جابهجا میشود، ولی برای فروردین تا آذر درست میماند. این یعنی باگ خودش را با ۹ ماه رفتار درست پنهان میکند.
این چرا در ERP مهمتر از جاهای دیگر است؟
سررسید چک، پایان دورهی مالیات بر ارزش افزوده و بستن سال مالی همگی دقیقاً در همین سه ماه رخ میدهند. یک روز جابهجایی در تاریخ سررسید چک یعنی گزارش «چکهای امروز» یا چیزی را جا میاندازد یا یک روز زودتر نشان میدهد — دقیقاً همان لحظهای که خطا گرانترین است.
چرا تست معمولی این را نمیگیرد؟
اگر تست فقط چند تاریخ «امروز» یا تاریخهای تصادفی را چک کند، احتمال برخورد با یکی از ۹۰ روز مشکلدار (سه ماه از ۳۶۵) حدود ۱۰٪ در هر اجراست — یعنی بهراحتی میتواند بارها سبز شود و باگ زنده بماند. تنها راه قطعی، تست رگرسیون با ground truth مستقل روی هر روز سه ماه پایانی سال، مقایسهشده با یک پیادهسازی دیگر که همان الگوریتم را ندارد.
راه بستن این کلاس باگ
- هر تبدیل تاریخ باید دوطرفه تست شود (رفتوبرگشت باید همان تاریخ اول را بدهد)، نه فقط یکطرفه.
- ground truth باید از یک پیادهسازی مستقل بیاید، نه از خودِ کدی که تست میشود.
- مرز سال (اسفند→فروردین) و مرز کبیسه باید صریحاً در فهرست تست باشند، نه امید به اینکه تست تصادفی به آنها برخورد کند.
بستهی ایران سرور MCP ابرک تبدیل شمسی را دقیقاً با همین روش — رگرسیون روی مرز کبیسه، ground truth مستقل — تست میکند، و همین روش یک باگ واقعی از همین کلاس را پیش از انتشار پیدا کرد.
