Проблема 2038 року: відмінності між версіями
| [неперевірена версія] | [неперевірена версія] |
м робот додав: ml:വൈ. 2 കെ. 38 |
Ilya (обговорення | внесок) мНемає опису редагування |
||
| Рядок 2: | Рядок 2: | ||
'''Пробле́ма 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 int<code> (32-бітового цілого із знаком). Найпізніша дата, яка може бути представлена таким форматом в стандарті [[POSIX]] - це 03:14:07, вівторок, [[19 січня]] 2038 року за [[UTC|всесвітнім часом (UTC)]]. |
На більшості 32-бітових систем використовується тип даних <code>time_t</code> для зберігання секунд у вигляді <code>signed int</code> (32-бітового цілого із знаком). Найпізніша дата, яка може бути представлена таким форматом в стандарті [[POSIX]] - це 03:14:07, вівторок, [[19 січня]] 2038 року за [[UTC|всесвітнім часом (UTC)]]. |
||
Наступний момент часу час змусить таке поле даних прийняти від'ємне значення, що подібно до закільцювання часу. Оскільки негативне число може бути сприйнято програмами як час в [[1970]] або [[1901]] року, залежно від реалізації. В результаті можуть бути проведені помилкові обчислення або отримані некоректні результати. |
Наступний момент часу час змусить таке поле даних прийняти від'ємне значення, що подібно до закільцювання часу. Оскільки негативне число може бути сприйнято програмами як час в [[1970]] або [[1901]] року, залежно від реалізації. В результаті можуть бути проведені помилкові обчислення або отримані некоректні результати. |
||
| Рядок 8: | Рядок 8: | ||
Для проблеми 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 залишиться актуальною. |
||
Версія за 19:45, 24 квітня 2009
Пробле́ма 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 року. Але ця проблема на даний момент не вважається терміновою.