Ви, напевно, пам’ятаєте паніку, пов’язану з проблемою Y2K. ЗМІ із задоволенням пророкували глобальний колапс, коли годинник пробив 2000 рік. Але в той час як багато застарілих систем було тоді «затягнуто», у фоні значної частини сучасного інтернету продовжує цокати інший таймер. Він називається “проблема 2038 року”. І вона корениться у тому, як мови програмування C обробляють час.
Більшість людей помилково вважають, що проблема пов’язана з двозначними роками, як у Y2K. Насправді, це не так. Корінь проблеми лежить глибше у коді. А саме – у тому, як програми на C зберігають дані про дату.
Обмеження 32-бітної архітектури
Ось технічна реальність. Стандартна бібліотека часу C використовує 4-байтове знакове ціле число для відстеження часу. Це 32 біти. Цей формат визначає «епохальний час» (epoch time), починаючи з 1 січня 1970 о 00:00:00 по UTC. Кожна секунда після цього моменту зберігається як просте число.
Наприклад, мітка часу 919642718 є 919 мільйонів секунд, що пройшли з початку епохи. Це відповідає 21 лютого 1999 року. Це зручно, тому що віднімання однієї мітки часу з іншої дає точну кількість секунд між двома подіями. Бібліотеки потім перетворять ці секунди на хвилини, години або роки.
Але є жорстка межа.
Максимальне значення знакового 32-бітного цілого числа дорівнює 2147483647. Як тільки цей лічильник досягає нуля секунд після 1 січня 1970 року, відбувається переповнення (перехід через нуль).
Це переповнення відбувається 19 січня 2038 року.
Після цієї дати ціле число переповнюється. Воно перетворюється на негативне число. Для системи, покладається цей формат, це негативне значення є недійсною датою. По суті, це збій у матриці для будь-якого програмного забезпечення, яке не було оновлено.
Чому це простіше, ніж проблема Y2K
Гарна новина? Виправлення цієї проблеми не таке брудно, як кошмари з мейнфреймами кінця 90-х.
У випадку з Y2K багато систем не стандартизували спосіб зберігання дат. Деякі використовували формат ММ-ДД-РР. Інші – ГГ-ММ-ДД. Відсутність універсального формату означала, що розробникам доводилося шукати код у кожному додатку та вручну змінювати логіку роботи з датами.
Проблема 2038 року чистіша.
Стандартна бібліотека часу інкапсулює весь процес обліку часу. Вона визначає свої власні типи та функції. Тому добре написані програми можна просто перекомпілювати. Інженерам потрібно лише замінити бібліотеку на версію, яка використовує більший розмір у байтах.
Наприклад, перехід від 4-байтового цілого числа до 8-байтового значно розширює діапазон. Знакове 8-байтове ціле число може вважати далеко за межі 2038 без переповнення. Це програмне оновлення. Чи не заміна обладнання. Чи не переписування коду. Просто заміна бібліотеки.
Windows і Mac: різні таймери, різні проблеми
Не всі системи використовують 32-бітний формат C. Різні операційні системи мають особливості.
Windows NT, наприклад, використовує 64-бітове ціле число. Вона відстежує час із кроком у 100 наносекунд. Але відлік починається ні з 1970 року, і з 1 січня 1601 року. Це відсуває дату переповнення набагато далі. Ймовірно, Windows досягне своєї межі приблизно 2184 року.
Apple пішла іншим шляхом. Згідно з офіційною документацією Apple, macOS спроектована так, щоб залишатися коректною до 29940 року. Це приблизно 27 000 років відтепер. Так що, якщо ви використовуєте Mac, вам не потрібно турбуватися про те, що ваш календар «зламається» у 2038 році.
Хто ще в зоні ризику?
Основну небезпеку становлять системи з урахуванням Unix. Але вони не самотні.
Вбудовані системи (embedded systems) також уразливі. Багато пристроїв IoT, промислові контролери та старі сервери баз даних покладаються на той самий 32-бітовий формат часу. Якщо їх не було оновлено, вони почнуть неправильно інтерпретувати дати після 19 січня 2038 року.
Короткострокові рішення можуть включати патчінг програмного забезпечення для коректної обробки негативних значень часу. Але це лише тимчасовий захід. Постійне рішення потребує переходу на 64-бітний формат часу.
Питання не в тому, чи зламається код. Питання, чи будуть оновлені системи, на яких цей код працює, до того, як час закінчиться.
Більшість інфраструктури, яку ми покладаємося, вже перетворюється на 64-битный облік часу. Але не все. Старі сервери. Застаріле промислове встаткування. Деякі вбудовані логіки. Це слабкі ланки.
Коли настане 19 січня 2038 року, годинник досягне своєї межі. Для деяких систем це буде непомітною подією. Для інших – жорсткою зупинкою. Якщо ви чекатимете до останньої хвилини, у вас не залишиться багато часу на патчінг коду.
