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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Інтерактивний перегляд історії
(Переглянути усі неперевірені зміни)
[неперевірена версія][неперевірена версія]
← Попереднє редагуванняНаступне редагування →
Вилучено вміст Додано вміст
ВізуальнийВікірозмітка
IvanBot (обговорення | внесок)
Боти
238 646 редагувань
м replaced: на даний момент → в наш час
м правопис
Рядок 1: Рядок 1:
{{Автопереклад}}
{{Автопереклад}}


[[Файл:Year 2038 problem.gif|thumb|400px|Ілюстрація зациклення дати.]]
[[Файл:Year 2038 problem.gif|thumb|400px|Ілюстрація зациклення дати]]
'''Пробле́ма 2038 ро́ку''' в [[Обчислювальна техника|обчислювальній техніці]] — це очікувані збої в [[Програмне забеспечення|программному забезпеченні]] [[19 січня]] [[2038]] року. Дана проблема зачіпає програми і системи, в яких використовується представлення часу за стандартом [[POSIX]] ([[Unix time]]), який являє собою кількість секунд, що пройшли з [[1 січня]] [[1970]] року. Таке представлення часу — стандарт для [[Unix]]-подобних операційних систем (через розповсюджене використання мови [[Сі (мова програмування)|Сі]]).
'''Пробле́ма 2038 ро́ку''' в [[Обчислювальна техніка|обчислювальній техніці]] — це очікувані збої в [[Програмне забезпечення|програмному забезпеченні]] [[19 січня]] [[2038]] року. Дана проблема зачіпає програми і системи, в яких використовується представлення часу за стандартом [[POSIX]] ([[Unix time]]), який являє собою кількість секунд, що пройшли з [[1 січня]] [[1970]] року. Таке представлення часу — стандарт для [[Unix]]-подобних операційних систем (через розповсюджене використання мови [[Сі (мова програмування)|Сі]]).


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


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


Для проблеми 2038 року не існує простого рішення для існуючих комбінацій [[процесор|процесорів]] і [[операційна система|операційних систем]].
Для проблеми [[2038]] року не існує простого рішення для існуючих комбінацій [[процесор]]ів і [[операційна система|операційних систем]].


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


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


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


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


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


Представлення дати у [[Java]] ([http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Date.html java.util.Date]) і [[.NET]] ([http://msdn.microsoft.com/en-us/library/system.datetime(VS.71).aspx System.DateTime]) не мають цієї проблеми.
Представлення дати у [[Java]] ([http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Date.html java.util.Date]) і [[.NET]] ([http://msdn.microsoft.com/en-us/library/system.datetime(VS.71).aspx System.DateTime]) не мають цієї проблеми.

Версія за 12:14, 11 червня 2012

Ця стаття є сирим перекладом з іншої мови. Можливо, вона створена за допомогою машинного перекладу або перекладачем, який недостатньо володіє обома мовами. Будь ласка, допоможіть поліпшити переклад.
Ілюстрація зациклення дати

Пробле́ма 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-бітних систем все ще вводяться в лад в 2006 році, у тому числі і в вбудовуваних системах. Викликає сумнів, що вони всі будуть замінені до 2038 року. Не зважаючи на те, що середній період модернізації сучасних комп'ютерних систем складає 18-24 місяців, вбудовані комп'ютери можуть діяти без модернізації весь термін, який працюють системи, ними керовані. Наприклад, комп'ютери управління процесами моделі IBM 1800, випуск яких розпочато 1965 року, усе ще використовувалися на одній з атомних станцій у Канаді у 2006 році.

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

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

Представлення дати у Java (java.util.Date) і .NET (System.DateTime) не мають цієї проблеми.

Див. також

На цю статтю не посилаються інші статті Вікіпедії.
Будь ласка розставте посилання відповідно до прийнятих рекомендацій.
Отримано з https://uk.wikipedia.org/w/index.php?title=Проблема_2038_року&oldid=9698530