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

правопис, корекція перекладу, вікіфікація, стильові правлення
м (Вилучення 27 інтервікі, відтепер доступних на Вікіданих: d:q459405)
(правопис, корекція перекладу, вікіфікація, стильові правлення)
{{Автопереклад|дата=серпень 2009}}
 
[[Файл:Year 2038 problem.gif|thumb|400px|Ілюстрація зациклення дати при 32-бітовому представленні]]
'''Пробле́ма 2038 ро́ку''' в [[Обчислювальна техніка|обчислювальній техніці]] — це очікувані збої в роботі [[Програмне забезпечення|програмномупрограмного забезпеченнізабезпечення]] [[19 січня]] [[2038]] року. Дана проблема торкаєтьсястосується програм і систем, в яких використовується представлення часу за стандартом [[POSIX]] ([[Unix time]]),. якийЦей являєстандарт собоювикористовує кількість секунд, щоякі пройшли від початку «епохи», тобто з півночі [[1 січня]] [[1970]] року. Таке представлення часу — стандарт для [[Unix]]-подібних операційних систем (через розповсюджене використання мови [[Сі (мова програмування)|Сі]]).
 
На більшості систем з розрядністю процесора не вище 32-бітнихбіт системдля зберігання секунд використовується [[тип даних]] <code>time_t</code>, длявизначений зберігання секунд у виглядіяк <code>signed&nbsp;int</code>, тобто у [[Формати даних|форматі]] (32-бітного цілого числа із знаком). Найпізніша дата, яка може бути представлена таким форматом в стандарті [[POSIX]]&nbsp;— це 03:14:07, вівторок, [[19 січня]] [[2038]] року за [[UTC|всесвітнім часом (UTC)]].
 
Наступний момент часу час змусить таке поле даних прийняти від'ємне значення, що подібно до зациклювання часу (оскільки негативне число може бути сприйнято програмами як час у [[1970]] або [[1901]] році, залежно від реалізації). В результаті можуть бути здійснені помилкові обчислення або отримані некоректні результати.
 
Для проблеми [[2038]] року не існує простого рішення для існуючихбагатьох комбінацій [[процесор]]ів і [[операційна система|операційних систем]] не існує простого рішення проблеми [[2038]] року.
 
Розширення типу <code>time_t</code> до 64 біт порушить бінарну сумісність програм, існуючихзбережених даних, що зберігаються, і всього іншого, що використовує представлення часу в бінарному вигляді. А приведення <code>time_t</code> в ціле без знаку може порушити роботу програм, які обчислюють різницю в часі.
може порушити роботу програм, які обчислюють різницю в часі.
 
Більшістю операційних систем для 64-бітноїбітних архітектуриархітектур вже використовується 64-бітне представлення цілого в <code>time_t</code>. Перехід на такутакі архітектуруархітектури вже відбувається, і за прогнозами, він буде завершений до 2038 року.
 
Проте сотні тисяч 32-бітних систем все ще вводяться в лад в [[2006]] роціексплуатацію, у тому числі і ву [[вбудовані системи|вбудовуваних системах]] (наприклад, на 32-бітних процесорах архітектури [[ARM]] та на процесорах меншої розрядності). Викликає сумнів, що вони всі будуть замінені до 2038 року. Не зважаючи на те, що середній період модернізації сучасних комп'ютерних систем становить 18-24 місяців, вбудовані комп'ютери можуть діяти без модернізації весь термін, який працюють керовані ними системи. Наприклад, комп'ютери управління [[Технологічний процес|процесами]] моделі IBM 1800, випуск яких розпочато 1965 року, усе ще використовувалися на одній з атомних станцій у Канаді у 2006 році.
весь термін, який працюють системи, ними керовані. Наприклад, комп'ютери управління процесами моделі IBM 1800, випуск яких розпочато 1965 року, усе ще використовувалися на одній з атомних станцій у Канаді у 2006 році.
 
На додаток до цього, 32-бітний формат <code>time_t</code> також включенийвключено до специфікацій [[Формат файлу|форматів файлів]], таких як повсюдно поширений [[Архіватор|архівний]] формат [[ZIP]]. Формат файлу може існувати протягом часу, за який зміняться багато поколінь комп'ютерів, а це означає, що Проблема 2038 залишиться актуальною.
[[ZIP]]. Формат файлу може існувати протягом часу, за який зміняться багато поколінь комп'ютерів, а це означає, що Проблема 2038 залишиться актуальною.
 
Введення 64-бітного формату вносить нову дату «закільцюваннязакільцьовування» через приблизно 290 мільярдів років, в 15:30:08 [[UTC]] в неділю, [[4 грудня]] 292&nbsp;277&nbsp;026&nbsp;596 року. Але ця проблема в наш час не вважається терміновою.
 
Представлення дати у [[Java]] (<ref>[http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Date.html javaClass Date — JavaTM 2 Platform Standard Ed.util 5.Date0])</ref> і [[.NET]] (<ref>[http://msdn.microsoft.com/en-us/library/system.datetime(VS.71).aspx System.DateTime Structure — .NET Framework])</ref> не мають цієї проблеми.
 
== Див. також ==
* [[Проблема 2000 року]]
* [[Проблема 10000 року]]
 
== Примітки ==
{{Примітки}}
 
{{Проблемні дати}}