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

В інформатиці баги форматів часу та зберігання даних — це клас програмних помилок, які можуть привести до збоїв обробки даних та відображення неправильного системного часу. Зазвичай це прояви арифметичного переповнення. Найбільш відомим наслідком помилок такого роду є проблема Y2K, але також є багато інших дат, які викликали або теоретично можуть викликати збої в залежності від різних недоліків програмного забезпечення.

Електронне табло у Франції відображає некоректний час — 1900 рік замість 2000 через проблему 2000 року

1970 рік ред.

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

1975 рік ред.

4 січня стало переповнюватися 12-бітове поле, яке використовувалося для зберігання дати в операційних системах Decsystem 10. Були зафіксовані численні проблеми і збої, пов'язані з цією помилкою. У той час був розроблений альтернативний формат[1].

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 рік ред.

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

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

2010 рік ред.

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

Основною причиною була плутанина між шістнадцятковим та BCD-кодуванням чисел. Цифри від 0 до 9 в кожній із систем кодуються від 0016 до 0916. Але десяткове число 10 кодується в шістнадцятковій системі, як 0A16, а в BCD як 1016. Таким чином, у BCD-кодуванні число 1016 інтерпретується як шістнадцяткове кодування, тому помилково представляє десяткове число 16.

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

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

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

2013 рік ред.

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

2015 рік ред.

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

2038 рік ред.

Докладніше: Проблема 2038 року

2040 рік ред.

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

2048 рік ред.

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

2079 рік ред.

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

2080 рік ред.

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

2100 рік ред.

DOS та Windows ред.

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

Помилковий високосний рік ред.

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

2106 рік ред.

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

292 277 026 596 рік ред.

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

Проблема 292 277 026 596 року (приблизно   років у майбутньому) відбудеться, коли 64-бітний UNIX-час переповниться після неділі, 4 грудня 292 277 026 596 року нашої ери о 15:30:08 по UTC.

Примітки ред.

  1. Austein, Rob. DATE-86, or The Ghost of Tinkles Past. The Risks Digest. ACM Committee on Computers and Public Policy. Архів оригіналу за 28 грудня 2014. Процитовано 29 грудня 2014.