Проблема 2038 року: відмінності між версіями

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
[перевірена версія][перевірена версія]
Вилучено вміст Додано вміст
У комп'ютерній техніці
AndriiDr (обговорення | внесок)
Немає опису редагування
Рядок 34: Рядок 34:
[[Категорія:Помилки програмування]]
[[Категорія:Помилки програмування]]
[[Категорія:2030-ті]]
[[Категорія:2030-ті]]
[[Категорія:Windows]]
[[Категорія:Microsoft Windows]]

Версія за 13:53, 24 листопада 2019

Ілюстрація зациклення дати при 32-бітовому представленні

Пробле́ма 2038 ро́ку у комп'ютерних системах — очікувані збої в роботі програмного забезпечення 19 січня 2038 року. Дана проблема стосується програм і систем, в яких використовується представлення часу за стандартом POSIX (Unix time). Цей стандарт використовує кількість секунд, які пройшли від початку «епохи», тобто з півночі 1 січня 1970 року. Таке представлення часу — стандарт для Unix-подібних операційних систем (через розповсюджене використання мови Сі).

На більшості систем з розрядністю процесора не вище 32-біт для зберігання секунд використовується тип даних time_t, визначений як signed int, тобто у форматі 32-бітного цілого числа із знаком. Найпізніша дата, яка може бути представлена таким форматом в стандарті POSIX — це 03:14:07, вівторок, 19 січня 2038 року за всесвітнім часом (UTC).

Наступний момент часу час змусить таке поле даних прийняти від'ємне значення, що подібно до зациклювання часу (оскільки від'ємне число може бути сприйнято програмами як час у 1970 або 1901 році, залежно від реалізації). В результаті можуть бути здійснені помилкові обчислення або отримані некоректні результати.

Для багатьох комбінацій процесорів і операційних систем не існує простого рішення проблеми 2038 року.

Розширення типу time_t до 64 біт порушить бінарну сумісність програм, збережених даних і всього іншого, що використовує представлення часу в бінарному вигляді. А приведення time_t в ціле без знаку може порушити роботу програм, які обчислюють різницю в часі.

Більшістю операційних систем для 64-бітних архітектур вже використовується 64-бітне представлення цілого в time_t. Перехід на такі архітектури вже відбувається, і за прогнозами, він буде завершений до 2038 року.

Проте сотні тисяч 32-бітних систем все ще вводяться експлуатацію, у тому числі — у вбудовуваних системах (наприклад, на 32-бітних процесорах архітектури ARM та на процесорах меншої розрядності). Викликає сумнів, що вони всі будуть замінені до 2038 року. Не зважаючи на те, що середній період модернізації сучасних комп'ютерних систем становить 18-24 місяців[джерело?], вбудовані комп'ютери можуть діяти без модернізації весь термін, який працюють керовані ними системи. Наприклад, комп'ютери управління процесами моделі IBM 1800, випуск яких розпочато 1965 року, усе ще використовувалися на одній з атомних станцій у Канаді у 2006 році.

На додаток до цього, 32-бітний формат time_t також включено до специфікацій форматів файлів, таких як повсюдно поширений архівний формат ZIP. Формат файлу може існувати протягом часу, за який зміняться багато поколінь комп'ютерів, а це означає, що Проблема 2038 залишиться актуальною.

Введення 64-бітного формату вносить нову дату «закільцьовування» через приблизно 290 мільярдів років, в 15:30:08 UTC в неділю, 4 грудня 292 277 026 596 року. Але ця проблема в наш час не вважається терміновою.

Представлення дати у Java[1] і .NET[2] не мають цієї проблеми.

Примітки