لطفا جاواسکریپت مرورگر خود را فعال سازید!

نحوه فعال سازی در کروم
  1. ابتدا باید اینکارو بگنید
  2. بعدش اونکارو
نحوه فعال سازی در فایرفاکس
  1. ابتدا باید اینکارو بگنید
  2. بعدش اونکارو
مشکل سال 2038 در لینوکس چیست؟ آیا قرار است یونیکس در 19 ژانویه 2038 از کار بیفتد؟

مشکل سال 2038 در لینوکس چیست؟ آیا قرار است یونیکس در 19 ژانویه 2038 از کار بیفتد؟

اگر مراحل توسعهٔ لینوکس را از نزدیک دنبال کرده باشید، احتمالاً اطلاعاتی راجع به باگ سال 2038 شنیده‌اید؛ این مشکل، مربوط به این قضیه است که آخرین زمانی که می‌توان توسط فرمت زمانی 32 بیتی اعداد صحیح به‌اصطلاح Signed در یونیکس نشان داد، دقیقاً تا ساعت 03:14:07 UTC در تاریخ 19 ژانویه 2038 تمام می‌شود. پس از آن، برنامه‌هایی که به زبان C نوشته شده‌اند و از لایبرری استاندارد تایم استفاده می‌کنند، در نمایش تاریخ به مشکل خواهند خورد!

مشکل سال 2000 که به باگ هزاره (Millennium Bug) یا مشکل Y2K نیز معروف است، باگی بود که به فرمت و ذخیره‌سازی تاریخ و تقویم مربوط می‌شد؛ این مساله به این خاطر به‌وجود آمد که ذخیره‌سازی دیتا در کامپیوترهای اولیه بسیار هزینه‌بر بود. بنابراین برای کاهش فضای ذخیره‌سازی، دولوپرها از فرمت 6 رقمی MMDDYY استفاده کردند (MM برای ماه، DD برای روز و YY برای سال.)

در آن سال‌ها که 19 سال تا رسیدن به پایان قرن بیستم زمان باقی مانده بود، با کاهش سایز فایل‌ها‌ و دیتابیس‌ها، پول بیشتری صرفه‌جویی می‌شد ولی بعدها مشخص شد که در این فرمت، میان سال 2000 و 1900 یا حتی 19100 تفاوتی دیده نمی‌شود.

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

مشکل سال 2038 که به باگ هزارهٔ یونیکس یا Y2K38 نیز معروف است، می‌تواند مشکلاتی در ذخیره‌سازی دیتا به‌بار آورد چراکه در برنامه‌های قدیمی، به‌خاطر استفاده از اعداد صحیح 32 بیتی Signed، بعد از آن تاریخ مقدار نادرستی نشان داده خواهد شد.

آخرین زمانی که به‌عنوان یک عدد 32 بیتی از جنس int می‌تواند در یونیکس به‌کار رود، 03:14:07 UTC در تاریخ 19 ژانویه 2038 است (به‌عبارت دیگر، یعنی 2147483647 ثانیه بعد از تاریخ 1 ژانویه 1970.) به زبان عامیانه، پس از این تاریخ به‌ دلیل سرریز شدن دیتا تایپ Integer، مقدار ذخیره شده به یک عدد منفی تبدیل خواهد شد و سیستم‌هایی که به‌روز نشده باشند، تاریخ را به جای 19 ژانویه 2038، به‌صورت 13 دسامبر 1901 نشان خواهند داد (سفری به گذشته!)

به عبارت دیگر، سیستم‌های یونیکسی به دلیل تمام شدن بیت‌ها برای شمارش ثانیه، به یک‌باره ریست می‌شوند. بنابراین در آن زمان، برنامه‌هایی که به زبان C نوشته شده‌اند و از لایبرری استاندارد تایم استفاده می‌کنند، شروع به ایجاد مشکل در نمایش تاریخ خواهند کرد (می‌توانید اطلاعات بیشتری را در صفحهٔ ویکیپدیای مشکل سال 2038 مطالعه کنید.)

در حال حاضر، راه‌حل جامعی برای باگ سال 2038 وجود ندارد؛ اگر قرار باشد تغییری در تعریف دیتا‌ تایپ time_t صورت بگیرد -که برای ذخیرهٔ مقادیر زمانی استفاده می‌شود- مشکلاتی مربوط به سازگاری، در برنامه‌هایی که به نوع اعداد صحیح 32 بیتی time_t وابسته هستند رخ خواهد داد.

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

سیستم‌عامل‌ها و برنامه‌های 64 بیتی، از اعداد صحیح 64 بیتی در time_t استفاده می‌کنند که بااستفاده از مقادیر Signed از نوع 64 بیتی، می‌توان 292 میلیارد سال از حال حاضر به بعد را نشان داد.

چندین طرح پیشنهادی ارائه شده است که شامل ذخیره‌سازی میلی‌ثانیه یا میکروثانیه از یک مبدأ تاریخ (مثلاً 1 ژانویه 1970 یا 1 ژانویه 2000) در اعداد صحیح Signed از نوع 64 بیتی می‌شود، که حداقل بازهٔ 300000 ساله‌ای را پوشش می‌دهد. پیشنهاد دیگر هم شامل ریکامپایل برنامه‌های قدیمی با استفاده از لایبرری‌های جدید تایم است. به هر ترتیب، کار همچنان ادامه دارد و طبق نظر متخصصین، برطرف کردن باگ سال 2038 نباید آن‌چنان هم سخت باشد.

منبع


مرتضی صمدی