Через 18 років, коли годинник проб’є 14 хвилин і сім секунд на третю ранку у вівторок 19 січня 2038 року по Грінвічу, світ сколихне баг, відомий як проблема 2038 року (або Y2038). Будь-який комп’ютер, програма, сервер або вбудована система, які зберігають час, використовуючи 32-розрядне ціле число зі знаком, вийдуть із ладу, якщо не будуть оновлені заздалегідь. Деяке програмне забезпечення, яке працює з майбутніми датами, вже почало давати збій, оскільки дану проблему не передбачали і не виправили раніше.

Майже всі операційні системи, які використовуються сьогодні, беруть свій початок від UNIX. Коли інженери розробили першу комп’ютерну операційну систему UNIX в 1970-х, вони довільно вирішили, що час буде представлено у вигляді 32-розрядного цілого числа зі знаком і буде вимірюватися як кількість секунд з 12:00:00 1 січня 1970 року. 32-бітові системи дати і часу можуть досягати тільки 2 147 483 647 секунд, що припадає відповідно на 19 січня 2038 року (3:14:08 ранку). У цей день будь-які програми на Сі, що використовують стандартну 32-бітну бібліотеку time_t, матимуть проблеми з обчисленням дати.

Проблема цілих чисел зі знаком полягає в тому, що вони не поводять себе як одометр автомобіля. Коли 5-значний одометр досягає 99 999 миль, а водій проїжджає ще одну милю, цифри «перевертаються» на 00000. Але коли ціле число зі знаком досягає максимального значення і потім збільшується, воно повертається до свого найменшого від’ємного значення. Додавання ще 1 до максимального значення 2 147 483 647 призведе до того, що ціле число обернеться на мінімальне значення -2 147 483 647, що відповідає 13 грудня 1901 року в 20:45:52 за Гринвічем. Отож, комп’ютер буде думати, що він здійснив подорож у часі. Це називається «переповненням цілих чисел» і означає, що в лічильнику закінчилися використовувані біти, і він починає проявлятися як негативне число.

Більшість допоміжних функцій, що використовують тип даних time_t, взагалі не можуть обробляти негативні значення time_t. Вони зазнають невдачі і повертають код помилки, і це призводить до аварійного завершення програми. Зокрема, ця проблема є актуальною для операційної системи Unix, яка підтримує телефони Android і Apple, а також для більшості інтернет-серверів. Деякі програми, які працюють з майбутніми датами, також можуть зазнавати збій раніше, ніж треба. Наприклад, програма, яка має справу з датами на 20 років вперед, повинна бути виправлена ​​не пізніше 2018 року.

Для планування Y2038 необхідний поетапний і випереджувальний підхід. Прямо зараз потрібно зосередитися на областях, що включають: 1) програмне забезпечення, яке обробляє майбутній час і дати; 2) формати повідомлень і файлів в мережі; 3) пристрої з тривалим строком служби.

В першу чергу слід сфокусуватися на програмному забезпеченні, яке має справу з майбутніми датами для обробки сертифікатів X.509 (наприклад, тих, які використовуються для HTTPS) і центрів сертифікації (ЦС) або для фінансового планування. У багатьох з цих сценаріїв проблеми вдалося вирішити, перемістивши застаріле програмне забезпечення з 32-розрядного цілого числа time_t на 64-розрядний time_t. В інших випадках потрібні більш значні зміни, особливо коли математичні значення перетворюються в цілі числа, коли задіяні формати провідників повідомлень або коли значення зберігаються в базах даних. Під час тестування та лагодження підтримки для 20-річних ЦС можуть бути задіяні низхідні залежності. Якщо дата, яка виходить за межі січня 2038 року, вводиться в систему ведення журналів або систему моніторингу, і якщо ці дані по черзі вводяться в системи оповіщення або бази даних звітів або системи забезпечення, то всі вони також можуть потребувати виправлення.

Коли 32-бітові мітки часу поміщаються в повідомлення, бази даних або формати файлів, вплив може виходити далеко за рамки конкретної системи. Це також системи з зовнішніми залежностями, де часто потрібно більш просунуте планування у вигляді взаємодії через кордони системи. Для цих наборів взаємодіючих систем можуть знадобитися зміни в певному порядку, і часто в гру вступає зворотна сумісність. Крім того, якщо існують формально або неофіційно стандартизовані протоколи, які використовують 32-бітові мітки часу в повідомленнях, будь-яка міграція або виправлення можуть бути засновані на виправленні стандарту. Важливо звернути увагу на такий ланцюжок залежностей:

• Оновлення протоколу/стандартів для підтримки часових відміток після Y2038.
• Реалізувати підтримку оновленого стандарту в бібліотеках програмного забезпечення.
• Отримати нову версію бібліотек, включених в пакети програм.
• Отримати пакети програмного забезпечення, включені в новий продукт доставки.

Якщо на кожен з цих етапів потрібно кілька років, а термін доставки товару – тривалий, то це може стати проблемою.

Пристрої з тривалим терміном служби також повинні бути в центрі уваги. Вбудовані пристрої, що поставляються з 32-бітовим обладнанням, не можуть бути легко виправлені за допомогою оновлення програмного забезпечення до 64-бітного time_t. Особливе занепокоєння, ймовірно, будуть викликати підключені автомобілі й інші пристрої IoT. З огляду на поточні тенденції, цілком ймовірно, що більше 10% проданих сьогодні автомобілів будуть як і раніше експлуатуватися в 2038 році, а зі збільшенням віку автомобілів і деяких автомобілів на дорозі цей відсоток може бути навіть вище. Через вісімнадцять років у нас може залишитися значна частина машин, що будуть мати серйозні проблеми. Схожа тенденція простежується в інших вбудованих системах, таких як домашні ігрові консолі та смарт телевізори, де пристрої можуть поставлятися з попередньо встановленими сертифікатами від 20 років.

Пристрої зв’язку, такі як стільникові телефони й інтернет-пристрої (маршрутизатори, точки бездротового доступу), є ще одним основним використанням вбудованих систем. Вони покладаються на зберігання точного часу і дати і все більше засновані на UNIX-подібних операційних системах. Люди повідомляли, що через Y2038 деякі пристрої, що працюють під управлінням 32-розрядної версії Android, при зміні часу на 19 січня 2038 року завершують роботу в аварійному порядку і не перезавантажуються.

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

Як і Y2K, це добре відома проблема, однак багато людей не вважають її серйозною загрозою. Загальне виправдання, яке можна знайти на форумах, полягає в тому, що до 2038 року 32-бітове програмне забезпечення або системи повністю вийдуть з ужитку. Але фіаско 2000 року показало, що всі недооцінюють довговічність програмної архітектури і то, наскільки вона буде вбудована.

Люди схильні бути недалекоглядними, думаючи про сьогодення більше, ніж навіть про найближче майбутнє. Програмісти були впевнені, що 2000 рік так далеко – на той час комп’ютери і програмне забезпечення безсумнівно будуть іншими! Їм не потрібно було турбуватися про це – аж до 1990-х років, коли Y2038 перестала бути надуманою проблемою і почала викликати у населення паніку, що породжувала найзловісніші попередження про загибель цивілізації.

Загальна вартість виправлення помилки 2000 року становила понад 300 мільярдів доларів, плюс ще кілька мільярдів, витрачених на рішення проблем, що виникли після початку тисячоліття. А коли настав 2000 рік, нічого катастрофічного не відбулося. Жоден із найстрашніших прогнозів не збувся. Це змусило багатьох повірити в те, що проблема була надмірно перебільшена.

Але кризи 2000 роки не було завдяки програмістам, які доклали зусиль, щоб виправити проблему, змінити мільйони рядків коду, аби дату представляли 8 цифр замість 6. Іронія в тому, що якщо ви виконуєте свою роботу належним чином, цього або ніхто не помічає, або вони можуть навіть поставити необхідність вашої роботи під сумнів.

Відсутність наслідків Y2K може привести до того, що організації і технологи будуть недостатньо підготовлені до Y2038. Неспеціалістам важче пояснити проблему Y2038, ніж Y2K, потенційно ускладнюючи розстановку пріоритетів і зосередження на поглибленій роботі. Повсюдність численних вбудованих пристроїв Інтернету речей (IoT) також значно збільшує потенційний вплив Y2038.

Рішення не є технічно складним. Потрібно лише переключитися на 64-бітові або більш високі бітові значення, що дасть більш високий максимум. За останнє десятиліття багато персональних комп’ютерів зробили цей перехід, особливо компанії, яким було необхідно прогнозувати час після 2038 року, як, наприклад банки, які мають справу з 30-річною іпотекою.

Apple стверджує, що iPhone 5S є першим 64-бітним смартфоном. Однак проблема 2038 року відноситься як до апаратного, так і до програмного забезпечення, тому, навіть якщо 5S використовує 64 біта, додаток будильника може бути 32-бітовим і тому також має бути оновленим.

Проблема не здається занадто актуальною – у нас є 18 років, щоб її виправити! – але її масштаб величезний. Щоб дати вам уявлення про те, як повільно корпорації можуть впроваджувати оновлення ПО, більшість банкоматів і раніше працювали на Windows XP і, таким чином, були уразливі для хакерів до 2018 року, хоча Microsoft припинила випуск продукту в 2007 році.

Тому важливо оновити ваші системи ЗАРАЗ і знати про постачальників, які відмовляються робити це вчасно, щоб уникнути дорогих і короткострокових виправлень для вашої системи і ПО.