Помните 1999 год, когда среди безумия по Spice Girls и массового сбора Beanie Babies все паниковали из-за Миллениум-бага (Проблема 2000 года)?
Опасение заключалось в том, что когда ’99 сменится на ’00, компьютеры не смогут распознать смену века; дата сбросится на 1900 год, и системы, зависящие от компьютеров по всему миру, выйдут из строя. Результат? От «нескольких забавных ошибок в электронных календарях» до «буквального краха цивилизации, какой мы её знаем» — в зависимости от того, кого вы спросили.
В конце концов, Новый год прошёл практически без происшествий — во многом благодаря огромным усилиям, предпринятым, чтобы предотвратить катастрофу. И всё, проблема решена, верно? Дальше всё должно идти как по маслу?
Погодите, неужели есть продолжение?
В чём заключается проблема 2038 года?
19 января 2038 года — день, когда время заканчивается. По крайней мере, если вы используете 32-битное Unix-время, которое применяется почти во всех компьютерах.
«Подписанное 32-битное целое число может хранить только числа от –2147483648 до 2147483647, — объясняет компания Tanium, специализирующаяся на кибербезопасности и управлении системами. — Это означает, что наибольший временной штамп, который могут обрабатывать такие системы, — это 2147483647, что соответствует 19 января 2038 года в 03:14:07 UTC.»
Эти числа не случайны. Хотя 2 147 483 648 кажется произвольным числом для человека, для компьютера, работающего в двоичной системе, это важная отметка: когда часы достигают 100 000 000 000 000 000 000 000 000 000 000. Для 32-битной системы это слишком много цифр, чтобы их можно было обработать, поэтому счётчик просто сбрасывается на самое начало.
«Временной штамп переполнится и станет отрицательным числом, что приведёт к неправильному отображению даты и времени, — поясняет Tanium. — Например, временной штамп 2147483648, который должен был бы соответствовать 03:14:08 UTC 20 января 2038 года, из-за переполнения превращается в –2147483648, что соответствует 13 декабря 1901 года в 20:45:52 UTC. Это и есть баг 2038 года.»
Должны ли мы беспокоиться?
С учётом всей паники вокруг проблемы Y2K, можно надеяться, что мы усвоили урок о необходимости подготовки. Мы узнали о баге 2038 года как минимум в 2006 году, когда аналогичная проблема произошла с программным обеспечением, поддерживающим веб-сервер AOL. Разве 32 лет недостаточно, чтобы найти решение?
На самом деле, существует довольно простой способ решения этой проблемы, и он прямо перед нами:
«Решение заключается в переходе на поддержку 64-битного времени, — писал Пол Бадд (Paul Budde), генеральный директор независимой консалтинговой компании Paul Budde Consulting, в статье для Independent Australia в 2022 году. — С 64 битами достаточно места для хранения временных значений далеко за пределами обозримого будущего, даже если используются значения времени с высокой точностью (основанные на наносекундах).»
64 бита могут показаться не намного больше 32, но когда речь идёт о степенях, разница огромна: это как разница между «13 годами» и «приблизительно 21-кратным возрастом Вселенной». Обновление до большего хранилища решило бы проблему настолько надолго, что её можно считать решённой навсегда. Так что, мы все уже массово перешли на 64-битные системы?
Похоже — нет.
«Некоторые типы баз данных, включая реляционные и NoSQL базы данных», по-прежнему полагаются на 32-битное время, отмечает Tanium, как и программы, написанные на языках, основанных на C, таких как C++ и PHP. Уязвимыми могут быть устройства на Windows, Linux, Android или iOS, а также «медицинские приборы, промышленные системы управления для объектов вроде электростанций, транспортные системы, автомобили с бортовыми компьютерами, маршрутизаторы, переключатели, сенсоры и устройства IoT, такие как умные бытовые приборы.»
В целом, это может привести к серьёзным сбоям. Так насколько мы готовы к этой проблеме?
Насколько мы готовы к багу 2038 года?
Точно сказать, насколько мы готовы к 2038 году, сложно. Новые операционные системы всё чаще используют 64-битное время. Но большая проблема заключается в уже существующих системах: переход с 32-битного времени на 64-битное для систем с открытым исходным кодом — задача «совсем не тривиальная», — как писал Михал Горни (Michał Górny), разработчик дистрибутива Linux Gentoo, в своём блоге в 2024 году.
«Прежде всего, речь идёт о разрушении совместимости ABI. Это либо всё, либо ничего, — писал он. — Если библиотека использует time_t в своём API, всё, что к ней подключается, должно использовать тот же размер типа […] смешивание программ и библиотек с использованием time32 и time64 может привести к серьёзным ошибкам во время выполнения.»
Даже если все системы, полагающиеся на 32-битное время, будут найдены и обновлены, последствия таких массовых изменений «необходимо тщательно исследовать, чтобы предотвратить нежелательные побочные эффекты», — предупреждает Бадд. «В свою очередь, эти решения могут создавать собственные побочные эффекты».
Учимся на ошибках
Представим, что проблему 2038 года решат полностью, и 20 января 2038 года не произойдёт ни одного сбоя. Можем ли мы расслабиться и забыть об этом?
Мы можем, но не стоит. Всего через несколько десятилетий нас ждёт новая проблема: 7 февраля 2106 года в 06:28:15 UTC ошибка затронет все системы, использующие беззнаковое 32-битное целое число для хранения времени.
Ещё через какое-то время Windows столкнётся с собственной версией бага:
«Windows NT использует 64-битное целое число для отслеживания времени, но его приращение составляет 100 наносекунд, а началом времени является 1 января 1601 года. Таким образом, Windows столкнётся с проблемой 2184 года.»
И дальше последуют баги 2262 года, 2446 года и другие. Программисты прошлого не могли предсказать, что их протоколы будут использоваться так долго. Но правда в том, что в будущем у нас, вероятно, будут гораздо более серьёзные проблемы.
