اگر در ویندوز روی فایلی راستکلیک کنید و پنجره «ویژگیها» را باز کنید، تاریخهای کاملاً عادیِ ایجاد، ویرایش و آخرین دسترسی به آن را خواهید دید. اما در سازوکار درونی ویندوز، یکی از روشهای بنیادی نمایش زمان فایلها، شمارش را از نقطهای بسیار نامعمول آغاز میکند: ۱ ژانویه ۱۶۰۱.
این تاریخ نه اشتباه تایپی است و نه یادگاری خاکخورده از دوران نخستین ویندوز برای حفظ سازگاری. هرچند چندین قرن پیش از پیدایش مایکروسافت و رایانش نوین قرار دارد، با دنبالکردن محاسبات تقویمیِ پشت آن، دلیل این انتخاب روشن میشود. طراحان ویندوز انتی میخواستند مسئلهای واقعی در ثبت و محاسبه زمان را حل کنند و سال ۱۶۰۱ نقطه آغاز بینقصی در اختیارشان میگذاشت.
ویندوز تمام این مدت از سال ۱۶۰۱ میشمرده است
پشت فایل اکسپلورر، زمانسنجی غولآسا پنهان است
ویندوز لازم نیست برچسب زمانی را بهصورت متنی خوانا برای انسان، مانند «۱۵ سپتامبر ۲۰۲۶، ساعت ۲:۳۰ بعدازظهر»، ذخیره کند. رایانهها بهسادگی زمان را در قالب عدد نگه میدارند و فقط هنگامی که لازم باشد آن را به ما نشان دهند، این اعداد را به تاریخ تقویمی برمیگردانند.
یکی از قالبهای اصلی نمایش زمان در ویندوز FILETIME است. مایکروسافت آن را مقداری ۶۴ بیتی تعریف میکند که تعداد بازههای ۱۰۰ نانوثانیهای سپریشده از ساعت ۰۰:۰۰ روز ۱ ژانویه ۱۶۰۱ به وقت UTC را میشمارد. استفاده از UTC بهعنوان معیار مشترک زمان نیز باعث میشود برچسب زمانیِ زیربنایی به منطقه زمانی محلیِ تنظیمشده روی رایانه وابسته نباشد.
به بیان دیگر، ویندوز هر ثانیه را به ۱۰ میلیون بازه ۱۰۰ نانوثانیهای تقسیم میکند. تاریخ ژانویه ۱۶۰۱ همان «مبدأ زمانی» است؛ نقطه صفر ثابتی که شمارش از آن آغاز میشود. زمان یونیکس ثانیهها را از مبدأ ۱ ژانویه ۱۹۷۰ میشمارد، اما ویندوز خط آغازی را برگزیده که تقریباً چهار قرن زودتر است.
بنابراین وقتی ویندوز میگوید فایلی دیروز ایجاد شده، بدیهی است که منظورش این نیست که آن فایل از روزگار الیزابت اول وجود داشته است. در سطح رابط برنامهنویسی، این برچسب زمانی را میتوان صرفاً با عددی بسیار بزرگ نمایش داد که جایگاه دیروز را روی آن خط زمانی مشخص میکند.
البته نکته مهمی در این میان وجود دارد. همه سامانههای فایل، برچسبهای زمانی را عیناً بهشکل مقدار FILETIME و با شمارش از سال ۱۶۰۱ ذخیره نمیکنند. NTFS برچسبهای زمانی را بر پایه UTC و با دقت ۱۰۰ نانوثانیه نگه میدارد، درحالیکه FAT از قالبها، دقتها و شیوههای متفاوتی برای برخورد با منطقه زمانی بهره میگیرد. سپس هرگاه نرمافزاری این مقادیر را بخواند، ویندوز میتواند مقدار ویژه هر سامانه فایل را به قالبهای زمانی استاندارد خود تبدیل کند.
همین نکته توضیح میدهد که چرا واحدهای ۱۰۰ نانوثانیهای به این معنا نیستند که ویندوز همیشه میتواند زمان دقیق رخدادن یک رویداد برای فایل را تا یک دهمیلیونیم ثانیه تعیین کند. قالب زمانی از چنین دقت ریزی پشتیبانی میکند، اما ممکن است سامانه فایل زیربنایی چنین توانی نداشته باشد.
مایکروسافت ۱۶۰۱ را برگزید، چون محاسبات تقویمی دردسرسازند
چرخه ۴۰۰ ساله، آشفتگی تقویم را رام میکند
تقویم میلادی از قواعدی انباشته است که گویی دقیقاً برای آزار برنامهنویسانِ سامانههای تاریخ طراحی شدهاند. بیشتر سالها ۳۶۵ روز دارند و معمولاً هر چهارمین سال، روز ۲۹ فوریه را نیز در خود جای میدهد. سالهای آغاز سده این الگو را بههم میزنند، زیرا سالهای بخشپذیر بر ۱۰۰ معمولاً آن روز اضافه را ندارند؛ مگر آنکه بر ۴۰۰ نیز بخشپذیر باشند که در این صورت دوباره کبیسه به شمار میآیند. به همین دلیل سال ۲۰۰۰ کبیسه بود، اما ۱۹۰۰ کبیسه نبود و ۲۱۰۰ نیز نخواهد بود.
بخش سودمند ماجرا برای برنامهنویسان زمانی آشکار میشود که یک بازه کامل ۴۰۰ ساله را بررسی کنیم. در یک چرخه کامل، ۹۷ سال کبیسه و ۳۰۳ سال عادی وجود دارد که در مجموع ۱۴۶,۰۹۷ روز میشود. اگر این عدد را بر هفت تقسیم کنیم، دقیقاً به ۲۰,۸۷۱ هفته میرسیم.
این بخشپذیری دقیق باعث میشود الگوی سالهای کبیسه تکرار شود و تاریخهای تقویمی دوباره با همان روزهای هفته همزمان شوند. بنابراین نرمافزار میتواند بهجای آنکه تقویم را رشتهای بیپایان از استثناهای بیارتباط بداند، با یک چرخه کامل و تکرارشونده کار کند. سال ۱۶۰۱ نیز صرفاً سالی قدیمی نبود که اتفاقی با این محاسبات جور دربیاید؛ این سال آغاز نخستین چرخه ۴۰۰ ساله تقویم میلادی بود که هنگام طراحی ویندوز انتی همچنان در جریان بود و سالهای ۱۶۰۱ تا ۲۰۰۰ را در بر میگرفت.
این توضیح را نیز برنامهنویسان سالها بعد با مهندسی معکوس به دست نیاوردند. ریموند چن، مهندس باسابقه مایکروسافت، در وبلاگ «چیز قدیمیِ نو» مایکروسافت مستقیماً به این پرسش پاسخ داده است. او توضیح داد که ۱۶۰۱ آغاز آن چرخه ۴۰۰ ساله بوده و گفت ایمیلی از دیو کاتلر، معمار ویندوز انتی، در اختیار دارد که این استدلال را تأیید میکند.
پس مایکروسافت قصد نداشت با انتخاب ۱ ژانویه ۱۶۰۱، رویداد ویژهای را گرامی بدارد. مهندسان فقط به مرزی دقیق و سازگار با محاسبات نیاز داشتند و تقویم میلادی چنین مرزی را در اختیارشان گذاشت.
مبدأ زمانی ۴۲۵ ساله، واقعاً قدیمی و منسوخ نیست
عقربههای ساعت ویندوز هنوز راه درازی در پیش دارند
وقتی نخستین بار با مبدأ زمانی ۱۶۰۱ آشنا شدم، واکنشم این بود که ویندوز لابد یکی دیگر از آن انتخابهای طراحی قدیمی را با خود یدک میکشد که سرانجام روزی مایهٔ پشیمانیمان خواهد شد. تاریخ رایانش به ما آموخته است هرگاه تاریخها و اعداد صحیح با اندازهٔ ثابت در یک بحث کنار هم قرار میگیرند، کمی نگران شویم.
مقایسهٔ آشکار، مشکل سال ۲۰۳۸ است. زمان سنتی یونیکس ثانیهها را از ۱ ژانویهٔ ۱۹۷۰ میشمارد و نرمافزارهایی که time_t را در قالب یک عدد صحیح علامتدار ۳۲-bit ذخیره میکنند، در ۱۹ ژانویهٔ ۲۰۳۸ دیگر مقدار مثبت تازهای در اختیار ندارند. سیستمعاملهای امروزی تا حد زیادی به نمایشهای گستردهتر برای زمان روی آوردهاند، اما نرمافزارهای قدیمی ۳۲-bit، رابطها و سامانههای توکار همچنان ممکن است به این سقف برسند.
بسیار قدیمیتر بودن مبدأ زمانی ویندوز، آن را خودبهخود در برابر مشکلات مربوط به تاریخ مصون نمیکند. FILETIME نیز مقادیر بسیار بزرگی تولید میکند، زیرا بهجای ثانیههای کامل، بازههای ۱۰۰ نانوثانیهای را میشمارد.
این مهلت بسیار طولانی عمدتاً از بهکارگیری نمایش ۶۴-bit سرچشمه میگیرد، نه شمارندهٔ علامتدار ۳۲-bit که زمینهساز مشکل کلاسیک سال ۲۰۳۸ است. مستندات ویندوز همچنین میگویند SYSTEMTIME، یعنی ساختار تفکیکشدهٔ تاریخ و زمان آن، از سالهای ۱۶۰۱ تا ۳۰۸۲۷ پشتیبانی میکند. بنابراین، این شیوهٔ خاص زمانسنجی با هیچ بحرانی شبیه مشکل سال ۲۰۳۸ روبهرو نیست.
سال ۱۶۰۱ مضحک به نظر میرسد؛ تا وقتی حسابوکتابش را بررسی کنید
همین نکته است که مبدأ زمانی ۱۶۰۱ را به یکی از شگفتیهای سرگرمکنندهٔ ویندوز بدل میکند. مهندسان ویندوز انتی، آغاز یک چرخهٔ تقویمی تکرارشوندهٔ ۴۰۰ساله را برگزیدند و آن را با قالب زمانی چنان گستردهای همراه کردند که بتواند مدت بسیار زیادی به کار خود ادامه دهد.
بیش از سه دهه پس از ورود ویندوز انتی، ویندوز ۱۱ هنوز زمان را از همان نقطهٔ آغاز میشمارد. سال ۱۶۰۱ نامعقول به نظر میرسد؛ تا وقتی واقعاً حسابوکتابش را انجام دهید.
منبع: این مطلب ترجمه و بومیسازی مقالهای از MakeUseOf به قلم Oluwademilade Afolabi است. مشاهده مقاله اصلی