باگی ۴۰ ساله در هر نسخه اکسل وجود دارد و مایکروسافت می‌گوید هرگز آن را رفع نخواهد کرد.

این یک ترفند سرگرم‌کننده است که در هر نسخه اکسل تا به حال عرضه شده، کار می‌کند. یک صفحه خالی باز کنید، در یک سلول ۶۰ تایپ کنید و آن سلول را به عنوان تاریخ فرمت کنید. اکسل با اطمینان ۲۹ فوریه ۱۹۰۰ را گزارش خواهد کرد.

تقویم را بررسی کنید. ۱۹۰۰ سال کبیسه نبود. فوریه ۲۸ روز داشت، و ۲۹ فوریه به سادگی وجود نداشت. با این حال، پرکاربردترین نرم‌افزار تجاری در جهان، روزی را به خود اختصاص داده است که هرگز وجود نداشته است — و افرادی که این نرم‌افزار را نگهداری می‌کنند می‌دانند که اشتباه است، چهل سال است که می‌دانند، و عمداً تصمیم گرفته‌اند که آن را دقیقاً همان‌طور که هست رها کنند.

میانبری که آن را آغاز کرد.

Lotus ۱-۲-۳ می‌خواست حافظه را ذخیره کند.

در ژانویه ۱۹۸۳، شرکتی به نام Lotus Development، نرم‌افزار Lotus ۱-۲-۳ را که توسط Mitch Kapor و Jonathan Sachs برای رایانه IBM نوشته شده بود، عرضه کرد. این نرم‌افزار به شدت موفق بود. ظرف چند سال، نرم‌افزاری را که این دسته را اختراع کرده بود، یعنی VisiCalc، به زیر کشید و به صفحه گسترده‌ای تبدیل شد که کسب‌وکارهای آمریکایی با آن کار می‌کردند. اگر در اواسط دهه ۸۰ در امور مالی کار می‌کردید، با Lotus کار می‌کردید.

Lotus باید سریع و کوچک می‌بود، زیرا ماشین‌هایی که روی آن‌ها اجرا می‌شدند، هیچ‌کدام نبودند. یک تنظیمات معمولی PC-DOS حداکثر ۶۴۰ کیلوبایت حافظه داشت (کمتر از یک عکس در گوشی شما امروز) بنابراین برنامه نمی‌توانست تاریخ‌ها را به صورت فانتزی ذخیره کند. هر تاریخ را به عنوان یک عدد شمارشی ساده ذخیره می‌کرد. ۱ ژانویه ۱۹۰۰ عدد ۱ بود، روز بعد ۲ بود، و به همین ترتیب تا هر تاریخی که ممکن بود تایپ کنید.

مشکل سال‌های کبیسه بود: چگونه تصمیم می‌گیرید که یک سال، ۲۹ فوریه داشته باشد؟ پاسخ کتاب درسی پیچیده است. یک سال، سال کبیسه است اگر بر ۴ بخش‌پذیر باشد — به جز سال‌های قرن، که تنها در صورتی کبیسه هستند که بر ۴۰۰ نیز بخش‌پذیر باشند. ۱۹۰۰ بر ۱۰۰ بخش‌پذیر بود و نه بر ۴۰۰، بنابراین با وجود بخش‌پذیری بر ۴، روز کبیسه نداشت.

توسعه‌دهندگان Lotus از بخش پیچیده صرف‌نظر کردند. بررسی آن‌ها یک سوال پرسید: آیا سال بر ۴ بخش‌پذیر است؟ در یک پردازنده دهه ۱۹۸۰، این آزمایش تقریباً رایگان بود — ماشین می‌توانست با نگاهی به دو بیت آخر یک عدد باینری به آن پاسخ دهد — و پاسخ صحیح را برای تقریباً هر سالی که یک کاربر صفحه گسترده وارد می‌کرد، می‌داد. ۱۹۰۰ استثنای نادر بود.

بنابراین Lotus سال ۱۹۰۰ را به عنوان یک سال کبیسه پذیرفت و روزی را برای پر کردن این شکاف اختراع کرد. در عدد سریال ۶۰، ۲۹ فوریه ۱۹۰۰ متولد شد. این روز هرگز از بین نرفت.

مایکروسافت این باگ را عمداً کپی کرد.

بی‌عیب و نقص به معنای باگ به باگ بود.

مایکروسافت اکسل را در سال ۱۹۸۵ در مکینتاش عرضه کرد و در سال ۱۹۸۷ قصد داشت آن را به ویندوز بیاورد. مشکل این بود که Lotus ۱-۲-۳ بازار را در اختیار داشت، با نوعی تسلط بر بخش‌های مالی شرکت‌ها که هزینه‌های تغییر را enormous می‌کرد. هیچ‌کس صفحه گسترده‌ای را که تمام اعداد شرکتش در آن قرار دارد، حذف نمی‌کند مگر اینکه جایگزین آن بی‌عیب و نقص باشد.

بنابراین اکسل باید به روشی بسیار خاص بی‌عیب و نقص می‌بود: باید یک فایل Lotus را باز می‌کرد و هر عدد را به طور یکسان، تا آخرین اعشار، بدون هیچ شگفتی بازتولید می‌کرد. و سریال‌های تاریخ بخشی از این معامله بودند.

مهندسان مایکروسافت قانون سال کبیسه را کاملاً درک می‌کردند. رفع آن بی‌اهمیت بود. اما رفع آن همچنین سریال‌های تاریخ آن‌ها را یک عدد از هر فایل Lotus موجود خارج می‌کرد، و سازگاری تمام هدف بود. بنابراین آن‌ها تصمیمی گرفتند که امروز نیز باعث تعجب می‌شود: آن‌ها باگ را عمداً کپی کردند. در آنچه اکسل آن را ۱۹۰۰ Date System می‌نامد، سریال ۶۰ عمداً به عنوان ۲۹ فوریه ۱۹۰۰ کدگذاری شده است. این خطا با انتخاب به ارث برده شد.

ریشه سال‌های کبیسه.

بخش تاریخچه اضافی!

زمین حدود ۳۶۵.۲۴۲۱۹ روز طول می‌کشد تا یک بار به دور خورشید بچرخد. نه ۳۶۵. آن اعشار عجیب و غریب، منبع تمام سردردهای تقویمی است که انسان‌ها تا به حال داشته‌اند. اگر تقویمی با ۳۶۵ روز کامل بسازید، تقریباً یک چهارم روز را هر سال از دست می‌دهید، و پس از چند دهه، ماه‌های “تابستان” شروع به لغزش به سمت زمستان واقعی می‌کنند.

ژولیوس سزار اولین اقدام واقعی را برای رفع این مشکل در سال ۴۵ قبل از میلاد با تقویم ژولینی انجام داد. ستاره‌شناسان او آن عدد نامنظم را به ۳۶۵.۲۵ روز گرد کردند و یک چهارم از دست رفته را با افزودن یک روز اضافی هر چهار سال جبران کردند — قانونی که اکثر ما هنوز در ذهن خود داریم: اگر سال بر ۴ بخش‌پذیر باشد، سال کبیسه است. برای مدتی، این سیستم به زیبایی کار کرد.

مشکل این است که ۳۶۵.۲۵ برابر ۳۶۵.۲۴۲۱۹ نیست. کمی بیش از حد طولانی است — حدود ۱۱ دقیقه تصحیح بیش از حد در سال. یازده دقیقه به نظر هیچ می‌رسد، اما تقویم‌ها صبور هستند. این دقایق در حدود سه روز اضافی هر ۴۰۰ سال جمع می‌شوند، و در طول قرن‌ها، تقویم ژولینی به حدی دور شد که اعتدال بهاری، و با آن عید پاک، ده روز از آنچه کلیسا انتظار داشت فاصله گرفت.

این انحراف چیزی بود که در نهایت باعث اصلاح شد. در سال ۱۵۸۲، پاپ گریگوری سیزدهم تقویم گریگوری را که امروز استفاده می‌کنیم معرفی کرد، که قانون هر چهار سال سزار را حفظ می‌کند اما یک اصلاحیه اضافی برای سال‌های قرن به آن اضافه می‌کند.

آزمایش کامل به این صورت است: اگر سال بر ۴۰۰ بخش‌پذیر باشد، سال کبیسه است؛ در غیر این صورت، اگر بر ۱۰۰ بخش‌پذیر باشد، کبیسه نیست؛ در غیر این صورت، اگر بر ۴ بخش‌پذیر باشد، کبیسه است؛ در غیر این صورت، کبیسه نیست.

این دو بند اضافی، سه روز کبیسه را هر ۴۰۰ سال کاهش می‌دهند، که دقیقاً برای خنثی کردن خطای ۱۱ دقیقه‌ای سزار در سال و بازگرداندن تقویم به خورشید کافی بود.

۱۹۰۰ بر ۴ بخش‌پذیر است، که در آن یک بررسی تنبل متوقف می‌شود، اما همچنین بر ۱۰۰ بخش‌پذیر است و نه بر ۴۰۰ — بنابراین قانون گریگوری روز کبیسه را از آن انکار می‌کند. Lotus ۱-۲-۳ تنها سوال اول را پرسید، هرگز دو سوال آخر را نپرسید، و اینگونه روزی که تقویم به‌طور خاص برای حذف آن طراحی شده بود، برای همیشه در صفحه گسترده شما زندگی کرد.

باگ اکسل واقعاً یک فاجعه نیست.

افست خود را خنثی می‌کند.

تاریخ

تقویم واقعی

سریال اکسل

۱ ژانویه ۱۹۰۰

1

1

…

…

…

۲۸ فوریه ۱۹۰۰

59

59

۲۹ فوریه ۱۹۰۰

وجود ندارد!

۶۰—روز شبح‌گونه در اینجا قرار داده شده است.

۱ مارس ۱۹۰۰

60

۶۱—و همه چیز بعد از آن یک شیفت بالا می‌رود.

برای حدود ۹۹ درصد کارهایی که مردم در یک صفحه گسترده انجام می‌دهند، این باگ هیچ کاری نمی‌کند. به وضوح پنهان است زیرا خود را خنثی می‌کند.

فرض کنید تعداد روزهای بین ۱ جولای ۲۰۲۶ و ۱ آگوست ۲۰۲۶ را می‌خواهید. هر دوی این تاریخ‌ها از روز شبح‌گونه عبور می‌کنند، بنابراین هر دو دقیقاً همان افست یک روزه را حمل می‌کنند. وقتی اکسل یکی را از دیگری کم می‌کند، روز اضافی در هر دو طرف در هر دو انتهای تفریق قرار می‌گیرد و ناپدید می‌شود. هر شکافی بین دو تاریخ مدرن به همین ترتیب کار می‌کند — خطا به طور مساوی در هر دو عدد پخته شده است، بنابراین هرگز از ریاضیات جان سالم به در نمی‌برد.

افست تنها زمانی گاز می‌گیرد که نتواند خنثی شود. سه وضعیت این کار را انجام می‌دهند.

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

اگر در حال ارسال سریال‌های تاریخ خام بین اکسل و سیستمی هستید که تقویم واقعی را حفظ می‌کند (مانند پایگاه داده SQL، datetime پایتون، مهر زمان یونیکس و غیره)، باید افست را برای هر چیزی در حدود ۱۹۰۰ دستی اصلاح کنید وگرنه تاریخ‌های شما یک روز انحراف پیدا می‌کنند.

اکسل برای مک قبلاً به طور پیش‌فرض از یک ۱۹۰۴ Date System کاملاً متفاوت استفاده می‌کرد، که در آن سریال ۰، ۱ ژانویه ۱۹۰۴ بود، به‌طور خاص برای فرار از این آشفتگی. اگر فایلی را بین یک مک قدیمی و یک ماشین ویندوز بدون تبدیل جابجا کنید، تاریخ‌های شما می‌توانند تقریباً چهار سال بپرند.

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

“مایکروسافت اکسل به اشتباه فرض می‌کند که سال ۱۹۰۰ یک سال کبیسه است… اگرچه از نظر فنی امکان اصلاح این رفتار وجود دارد، اما معایب انجام این کار بیشتر از مزایای آن است.”

و اینگونه یک گوشه‌ای که دو برنامه‌نویس برای ذخیره چند بایت حافظه در یک برنامه DOS در سال ۱۹۸۳ قطع کردند، امروز یک الزام مستند در یک استاندارد بین‌المللی است. وقتی صحت و سازگاری به عقب با هم در جنگ هستند، صحت به ندرت پیروز می‌شود.

منبع: این مطلب یک بومیسازی و بازنویسی تحریریهای بر اساس مقالهای از MakeUseOf نوشته Amir Bohlooli است: مشاهده مقاله اصلی.