Перегляд вихідного коду сторінки Баги форматів часу та зберігання даних

{{перекласти|en|Time formatting and storage bugs}}
[[Файл:Bug_de_l'an_2000.jpg|міні|Електронне табло у Франції відображає некоректний час&nbsp;— 1900 рік замість 2000 через [[Проблема 2000 року|проблему 2000 року]]]]

В [[Інформатика|інформатиці]] '''баги форматів часу та зберігання даних'''&nbsp;— це клас програмних помилок, які можуть привести до збоїв [[Обробка даних|обробки даних]] та відображення неправильного [[Системний час|системного часу]]. Зазвичай це прояви [[Арифметичне переповнення|арифметичного переповнення]]. Найбільш відомим наслідком помилок такого роду є [[Проблема 2000 року|проблема Y2K]], але також є багато інших дат, які викликали або теоретично можуть викликати збої в залежності від різних недоліків [[Програмне забезпечення|програмного забезпечення]].

== 1970 рік ==
У [[1960-ті|1960-х]], деякі [[комп'ютерні програми]] були написані з використанням тільки однієї цифри для позначення конкретного року, тобто надавалась можливість зберігати 0-9 роки (1960—1969). Завдяки цьому обмеженню, програмування на мові [[COBOL]] було дуже зручним. Проблема була виявлена і виправлена до 1970 року, тому ніяких наслідків зафіксовано не було. Виправлення, проте, дало можливість зберігати рік всього у двох цифрах через обмеження носіїв у ту епоху.

== 1975 рік ==
4 січня стало переповнюватися 12-бітове поле, яке використовувалося для зберігання дати в операційних системах [[PDP-10|Decsystem 10]]. Були зафіксовані численні проблеми і збої, пов'язані з цією помилкою. У той час був розроблений альтернативний формат<ref>{{cite web|url=http://catless.ncl.ac.uk/Risks/4.45.html|title=DATE-86, or The Ghost of Tinkles Past|website=The Risks Digest|publisher=ACM Committee on Computers and Public Policy|accessdate=29 грудня 2014|last1=Austein|first1=Rob|archive-date=28 грудня 2014|archive-url=https://web.archive.org/web/20141228211038/http://catless.ncl.ac.uk/Risks/4.45.html}}</ref>.

== 1999 рік ==

=== 9/9/99 ===
У багатьох програмах набір даних «9/9/99» був використаний як «заглушка» (або [[Магічне число (програмування)]]), щоб вказати на некоректно введений формат часу. 9 вересня 1999 виникло багато збоїв на пристроях, що використовували подібну заглушку.

=== GPS передача даних ===
Інша проблема була пов'язана з [[GPS]] пристроями: дата виражалась як номер тижня і дня у тижні, що передавалися у 10-бітовому та 3-бітовому форматі відповідно. Це означає, що кожні 1 024 тижнів (близько 19,6 року), починаючи від 6 січня 1980 (початок GPS-епохи), номер тижня повертається до початкового значення. 21 серпня 1999 це значення вперше досягло свого максимуму. Для вирішення цієї проблеми було модернізовано формат передачі GPS-даних, який тепер використовує 13-бітове поле для дати. Таким чином формат вміщує 8 192 тижнів (157 років), і дата ніколи не повернеться до нуля до 2137 року.

== 2000 рік ==
{{Основна стаття|Проблема 2000 року}}

== 2001 рік ==
[[Файл:1000000000seconds.jpg|праворуч|міні|220пкс|Час Unix подолав відмітку в 1 000 000 000 секунд у 2001-09-09T01:46:40Z. Це було відсвятковано в [[Копенгаген]]і, на вечірці Датської групи користувачів UNIX d 03:46:40 за локальним часом.]]

9 вересня 2001 року в [[Час Unix|Unix-форматі]] часу кількість секунд, починаючи від опівночі (UTC) 1 січня 1970 досягла 1&nbsp;млрд. Програми, які використовували дев'ять цифр для зберігання часу не були в змозі правильно працювати.

== 2010 рік ==
У засобах масової інформації проблема відома під назвою «Y2K + 10» або «проблема Y2.01k».

Основною причиною була плутанина між [[Шістнадцяткова система числення|шістнадцятковим]] та [[BCD|BCD-кодуванням]] чисел. Цифри від 0 до 9 в кожній із систем кодуються від 00<sub>16</sub> до 09<sub>16</sub>. Але десяткове число 10 кодується в шістнадцятковій системі, як 0A<sub>16</sub>, а в BCD як 10<sub>16</sub>. Таким чином, у BCD-кодуванні число 10<sub>16</sub> інтерпретується як шістнадцяткове кодування, тому помилково представляє десяткове число 16.

Наприклад, протокол [[SMS]] використовує BCD-кодування, тому деякі оператори мобільного зв'язку неправильно визначили дати повідомлень (замість 2010 відображався 2016).

Також, збої сталися у багатьох [[Платіжний термінал|платіжних терміналах]], що унеможливило зарахування платежів.

У Німеччині понад 20 мільйонів банківських карток стали непридатними для використання.

== 2013 рік ==
Космічний апарат [[Deep Impact (космічний апарат)|Deep Impact]] втратив зв'язок із Землею в серпні 2013 року, після того, як його системний годинник нарахував 2^32 секунд, починаючи від 1 січня 2000 року.

== 2015 рік ==
Деякі застарілі мобільні телефони [[Samsung]] із чипсетами Agere (наприклад, Samsung SGH-C170) не могли зберігати дату після 31 грудня 2014 року. При ввімкнутому телефоні дата автоматично зміниться до 2015 року, але після циклу електроживлення (розрядженої батареї або при необхідності заміни SIM-карти, яка знаходиться позаду батареї в телефоні) автоматично скинеться до початкової. Єдиним способом відображати правильну дату на головному екрані є використання 1987 року замість 2015 (як сумісного високосного).

== 2038 рік ==
{{Основна стаття|Проблема 2038 року}}

== 2040 рік ==
[[HFS|Ієрархічна файлова система]] (HFS) компанії [[Apple Inc.|Apple]] і його наступниця {{не перекладено|HFS Плюс||en|HFS_Plus}}, що встановлені за умовчанням на всіх комп'ютерах [[Macintosh]], можуть представляти дати тільки в діапазоні від 1 січня 1904 року до 6 лютого 2040. З настанням цього часу почне переповнюватися відповідне системне поле. На даний момент Apple працює над цією проблемою та створює альтернативну файлову систему.

== 2048 рік ==
На GPS-пристроях, що передають дані у 32-розрядному форматі почне переповнюватися відповідне поле.

== 2079 рік ==
Наразі існує багато систем, що зберігають дату як кількість днів, що пройшли з довільної дати (або епохи). Такі системи уразливі при досягненні максимального значення. Наприклад поле дати у програмах, які зберігають кількість днів з 1 січня 1900 року у 16-бітному розмірі, переповнювалися б через 32 768 (2<sup>15</sup>) днів, тобто 18 вересня 1989 року. Але через обмеження носіїв у той час така практика ще не була запроваджена. Але програм, які зберігають кількість днів з 1 січня 1900 року у 32-бітному розмірі, на даний час вже багато, і вони почнуть переповнюватися через 65 536 (2<sup>16</sup>) днів, тобто 6 червня 2079 року.

== 2080 рік ==
Усі мобільні телефони марки [[Nokia]], які працюють на операційній системі [[Series 40]] (наприклад Nokia X2-00) підтримують дати до 31 грудня 2079 і не будуть змінюватися з настанням 2080 року. Для усунення проблеми можна використовувати 1996 рік замість 2080 (як сумісного високосного).

== 2100 рік ==

=== DOS та Windows ===
Цього року виникне масштабна проблема, оскільки операційні системи [[DOS]]&nbsp;та&nbsp;[[Windows]] офіційно підтримують дати до 2099-12-31. Тому ці ОС почнуть несподівану поведінку з настанням 1 січня 2100 року.

=== Помилковий високосний рік ===
Інша проблема виникне наприкінці 28 лютого, оскільки 2100 не є високосним роком, але багато розробників помилково вважають навпаки. Це призведе до неправильного відображення дати (після 28 лютого настане 29 лютого, замість 1 березня).

== 2106 рік ==
Цього року відбудеться один з наймасштабніших часових [[баг]]ів. Більшість форматів файлів, [[Комунікаційний протокол|комунікаційних протоколів]] та інтерфейсів [[Додаток (програма)|додатків]] використовують [[UNIX-час|Unix-час]], зберігаючи кількість секунд з початку Unix Epoch (UTC 00:00 1 січня 1970 року) як беззнакове 32-розрядне двійкове число. Це значення набуде максимуму 7 лютого 2106. (ця проблема зберігання також стосується 64-розрядних систем).

== 292 277 026 596 рік ==
Деякі проблематичні роки відбудуться так далеко в майбутньому (пізніше ніж очікувана тривалість життя [[Земля|Землі]], [[Сонце|Сонця]], людства, та навіть деяких передбачень тривалости життя Всесвіту), що їх зазвичай згадують як питання теоретичного інтересу, жарти, чи індикації, що схожа проблема ще не вирішена повністю.

'''Проблема 292 277 026 596 року''' (приблизно <math>2.9\cdot10^{9}</math> років у майбутньому) відбудеться, коли 64-бітний [[UNIX-час]] переповниться після неділі, 4 грудня 292 277 026 596 року нашої ери о 15:30:08 по [[UTC]].

== Примітки ==
{{reflist}}

{{Проблемні дати}}

[[Категорія:Проблеми дат у програмуванні| ]]
[[Категорія:Помилки програмування]]
[[Категорія:Календар]]