Проблема 2038 року: відмінності між версіями
| [неперевірена версія] | [неперевірена версія] |
Вилучено вміст Додано вміст
м робот змінив: fr:Bug de l'an 2038 |
Kergma (обговорення | внесок) Немає опису редагування |
||
Рядок 6:
На більшості 32-бітових систем використовується тип даних <code>time_t</code> для зберігання секунд у вигляді <code>signed int</code> (32-бітового цілого із знаком). Найпізніша дата, яка може бути представлена таким форматом в стандарті [[POSIX]] - це 03:14:07, вівторок, [[19 січня]] 2038 року за [[UTC|всесвітнім часом (UTC)]].
Наступний момент часу час змусить таке поле даних прийняти від'ємне значення, що подібно до закільцювання часу
Для проблеми 2038 року не існує простого рішення для існуючих комбінацій [[процесор|процесорів]] і [[операційна система|операційних систем]].
Рядок 16:
Проте сотні тисяч 32-бітових систем все ще вводяться в лад в [[2006]] році, у тому числі і в [[вбудовані системи|вбудовуваних системах]]. Викликає сумнів, що вони всі будуть замінені до 2038 року. Не дивлячись на те, що середній період модернізації сучасних комп'ютерних систем складає 18-24 місяців, вбудовані комп'ютери можуть діяти без модернізації
весь термін, який працюють системи, ними керовані. Наприклад, комп'ютери управління процесами моделі IBM 1800, випуск яких розпочато 1965 року, усе ще використовувалися на одній з атомних станцій у Канаді у 2006 році.
На додаток до цього, 32-бітовий формат <code>time_t</code> також включений
[[ZIP]]. Формат файлу може існувати протягом часу, за який зміняться багато поколінь комп'ютерів, а це означає, що Проблема 2038 залишиться актуальною.
Введення 64-бітового формату вносить нову дату «
Представлення дати у [[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]) не мають цієї проблеми.
| |||