پرش به محتوا
شروع رایگان

تقویم جلالی در ERP؛ باگ‌های پنهان تاریخ

یک باگ واقعی تبدیل شمسی که فقط در سه ماه پایانی سال رخ می‌داد — و چرا تست تصادفی آن را پیدا نمی‌کرد

یک تبدیل‌گر تاریخ شمسی که «امروز» را همیشه درست نشان می‌دهد، می‌تواند در ۱۰٪ تاریخ‌های سال کاملاً غلط باشد — و هیچ‌کس متوجه نشود، چون همان ۱۰٪ (سه ماه پایانی سال شمسی) دقیقاً جایی است که کمتر کسی به‌صورت دستی چک می‌کند.

چرا سه ماه پایانی سال، نقطه‌ی شکست رایج است؟

الگوریتم تبدیل شمسی به میلادی معمولاً اول اختلاف سال را کم می‌کند، بعد چک می‌کند سال کبیسه است یا نه. اگر ترتیب برعکس باشد — یعنی کبیسه‌بودن بعد از کم‌کردن سال چک شود — نتیجه برای دی، بهمن و اسفند (دقیقاً پایان سال مالی) یک روز جابه‌جا می‌شود، ولی برای فروردین تا آذر درست می‌ماند. این یعنی باگ خودش را با ۹ ماه رفتار درست پنهان می‌کند.

این چرا در ERP مهم‌تر از جاهای دیگر است؟

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

چرا تست معمولی این را نمی‌گیرد؟

اگر تست فقط چند تاریخ «امروز» یا تاریخ‌های تصادفی را چک کند، احتمال برخورد با یکی از ۹۰ روز مشکل‌دار (سه ماه از ۳۶۵) حدود ۱۰٪ در هر اجراست — یعنی به‌راحتی می‌تواند بارها سبز شود و باگ زنده بماند. تنها راه قطعی، تست رگرسیون با ground truth مستقل روی هر روز سه ماه پایانی سال، مقایسه‌شده با یک پیاده‌سازی دیگر که همان الگوریتم را ندارد.

راه بستن این کلاس باگ

  • هر تبدیل تاریخ باید دوطرفه تست شود (رفت‌وبرگشت باید همان تاریخ اول را بدهد)، نه فقط یک‌طرفه.
  • ground truth باید از یک پیاده‌سازی مستقل بیاید، نه از خودِ کدی که تست می‌شود.
  • مرز سال (اسفند→فروردین) و مرز کبیسه باید صریحاً در فهرست تست باشند، نه امید به این‌که تست تصادفی به آن‌ها برخورد کند.

بسته‌ی ایران سرور MCP ابرک تبدیل شمسی را دقیقاً با همین روش — رگرسیون روی مرز کبیسه، ground truth مستقل — تست می‌کند، و همین روش یک باگ واقعی از همین کلاس را پیش از انتشار پیدا کرد.

چهار باگ پنهان تاریخ که فقط در شرایط خاص ظاهر می شوند

  • آخر اسفند سال کبیسه: سیستم میلادی محور روز ۳۰ اسفند را نمی شناسد و سند به فروردین سرریز می شود
  • مرز ساعت صفر: سفارش ۰۰:۰۱ در گزارش دیروز نمی آید اما انبار همان شب کم کرده
  • سررسید چک آخر سال: محاسبه «۳۰ روز بعد» از اول اسفند ممکن است به ۳۰ یا ۳۱ اسفند برسد — دو رفتار متفاوت
  • خروجی اکسل: نمایش جلالی درست اما ذخیره میلادی؛ ممیز فایل را باز می کند و تاریخ عوض است!

تست چهار مورد بالا روی سیستم فعلی تان را جدی بگیرید؛ سناریوهای کامل در بدنه مقاله. راهکار پایدار: تقویم در لایه هسته مثل ماژول جلالی ابرک، نه تبدیل سطح نمایش.

چک‌لیست امنیتی کلیدهای MCP پیش از تحویل به AI

ابرک را رایگان امتحان کنید

شروع رایگان