Компьютерные ошибки апокалипсиса: баги с датами, которые чуть не разрушили цивилизацию

Первые звоночки Y2K

Одним из ранних проявлениев «проблемы 2000 года» был инцидент в британском супермаркете. В систему поступила партия консервов, срок годности которых истекал 01.01.2000, но программа посчитала, что продукт просрочен уже почти сто лет, и отправила его на списание.

Похожая история произошла в 1997 году в Италии: 104-летняя женщина получила уведомление о зачислении в детский сад. Причина — ошибка в алгоритме, рассчитывающем возраст по дате рождения.

Проблемы возникали и в финансовом секторе. Ряд банкоматов отказывался принимать карты со сроком действия, истекающим в 2000 году, — ПО считало их уже просроченными, так как 00 воспринималось как 1900.

Ситуация вышла на новый уровень, когда в США два федеральных министерства сообщили о сбоях в своих IT-системах, связанных с переходом на новый век. Ошибки в расчётах мешали планировать бюджет, вести учёт и прогнозировать события.

Попытки предотвратить цифровой коллапс

В 1998 году президент США Билл Клинтон подписал указ о создании комитета по решению «проблемы 2000 года». Страны — участницы G8 согласились, что проблема есть, и тоже создали комитеты и советы. В России проблемой глобального компьютерного сбоя занимались Государственный комитет по связи и информатизации и специальная правительственная комиссия, созданная при поддержке Совета безопасности.

Корпорации тоже начали помогать исправить ошибку. Их подход был прост: дать денег — и как можно больше. Например, телекоммуникационная компания AT&T в конце 1990-х тратила на борьбу с багом 500 миллионов долларов в год. Генеральный директор AT&T в шутку жаловался, что у программистов получалось выйти за рамки практически безграничного бюджета.

По разным оценкам, мировые расходы на решение «Проблемы 2000 года» варьировались от 300 до 600 миллиардов долларов. Средства уходили на аудит систем, переписывание кода, обновление оборудования, тестирование и наём консультантов.

Пока политики созывали комиссии, а консультанты выступали на форумах, реальную работу делали программисты. Их задача была предельно проста по формулировке: найти и исправить все участки кода, где годы хранились в форме двух цифр. Но на практике это означало анализ миллионов строк, написанных десятилетия назад, часто без документации и стандартизации.

Решений было немного — и ни одно из них не было идеальным.

Решение 1

Добавить столетие

Один из очевидных способов — просто добавить два дополнительных разряда для хранения века. Например, структура даты в COBOL могла выглядеть так:

01 EMP-HIRE-DATE. 
   03 EMP-HIRE-DATE-YR. 
      05 EMP-HIRE-DATE-CC    PIC 99. 
      05 EMP-HIRE-DATE-YY    PIC 99. 
   03 EMP-HIRE-DATE-MM        PIC 99. 
   03 EMP-HIRE-DATE-DD        PIC 99. 

В ней:

• EMP-HIRE-DATE — имя переменной, представляющей дату целиком.
• EMP-HIRE-DATE-YR — вложенная структура для записи года.
• EMP-HIRE-DATE-CC — век, например 19 для 1999-го или 20 для 2023-го.
• EMP-HIRE-DATE-YY — последние две цифры года, например 99 для 1999 или 23 для 2023.
• EMP-HIRE-DATE-MM — месяц (01–12).
• EMP-HIRE-DATE-DD — день (01–31).

Такой подход был надёжен: дата становилась четырёхзначной и проблема откладывалась как минимум до 9999 года. Но был и минус: во многих системах, особенно написанных на старом COBOL, приходилось переделывать логику хранения, вывода и сравнения дат, что означало рефакторинг почти всех бизнес-процессов.

Читайте также:

COBOL жив! Что? Да!

Решение 2

Условная интерпретация года

Другой подход — условная интерпретация года. Программа просто проверяла, к какому веку относится дата. Например:

IF EMP-HIRE-DATE-YY > 50 
    MOVE 19 TO PRINT-HIRE-DATE-CC
ELSE 
    MOVE 20 TO PRINT-HIRE-DATE-CC

Этот метод был быстрым и дешёвым, поэтому его активно использовали в 1990-х. Однако решение было только временным, так как программа могла запутаться в интерпретации даты. Например, число 20 в коде могло быть как 1920-м, так и 2020 годом.

Решение 3

Компромиссное хранение

В некоторых системах дата хранилась в 3 байтах, упакованных в 4-битные сегменты. Это позволяло разработчикам добавить в формат даты дополнительный байт под столетие без кардинальной перестройки. Этот способ позволял отсрочить коллапс до 2100 или 2900 года — в зависимости от схемы кодирования.

Последствия Y2K

В роковую ночь с 31 декабря 1999 года на 1 января 2000 года Питер де Ягер был в самолёте. Он хотел на личном примере показать всему миру, что проблема решена и никаких кризисов не будет: самолёты не упадут, электростанции не взорвутся.

Масштабных сбоев в 2000 году не было, но появились локальные ошибки в системах, которые работали на устаревшем ПО:

• В Японии и Австралии были сбои в работе автобусов, в Китае в полночь вышли из строя таксометры.
• В Гонконге, на радость людям, у полиции перестали работать алкотестеры.
• В Греции около 10% кассовых аппаратов выдали чеки за 1900 год.
• В Дании компьютер решил, что первому ребёнку, родившемуся в 2000 году, уже 100 лет.
• Салоны видеопроката в США и Южной Корее выписали клиентам штрафы за то, что те не вернули видеокассеты вовремя. Вернуть их надо было 100 лет назад.
• В итальянской судебной системе из-за сбоя некоторым заключённым увеличили срок на 100 лет, а других программа, наоборот, порекомендовала выпустить на свободу.

В Германии банк случайно перевёл клиенту 12 миллионов марок, оформив транзакцию на 30 декабря 1899 года.

В некоторых регионах заметили и более серьёзные последствия. Например, в больницах Египта, Швеции и Южной Корее перестали работать аппараты для гемодиализа и ЭКГ. В Великобритании возраст некоторых беременных женщин неправильно отобразился в программе для оценки риска синдрома Дауна. Из-за этого пострадали 154 пациентки.

Не ошиблись аналитики и насчёт атомных электростанций: в Японии на АЭС «Сика» вышло из строя оборудование для радиационного контроля. К счастью, сбой быстро устранили и аварий не произошло.

В целом же последствия и ущерб от Y2K признали незначительными. Мир вздохнул спокойно. Правда, некоторые журналисты попытались разоблачить Роберта Бемера, Питера де Ягера и других жадных компьютерщиков, которые «нажились на выдуманной проблеме».

Проблема 2038 года

После Y2K казалось, что человечество извлекло урок. Но на горизонте уже маячит новый временной баг — и снова связанный с тем, как машины представляют даты. Речь о проблеме 2038 года (Y2038), актуальной для систем, работающих на 32-битных Unix-подобных ОС.

Читайте также:

Что такое Linux: гайд по самой свободной операционной системе

Суть проблемы

Отсчёт времени в Unix-системах ведётся от «эпохи Unix» — нуля, зафиксированного в 00:00:00 UTC 1 января 1970 года. Время хранится как количество секунд, прошедших с этого момента, и кодируется целым знаковым числом (signed int) в 32 бита.

Максимальное значение, которое можно представить в таком формате, — 2 147 483 647 секунд. Это соответствует дате: 03:14:07 UTC 19 января 2038 года. После этой отметки счётчик переполнится и начнёт отсчёт с −2 147 483 648, что может быть интерпретировано системой как 13 декабря 1901 года.

Последствия бага зависят от того, как конкретная программа использует время. Например, часы на некоторых компьютерах просто перестанут работать или уйдут в прошлое на почти 137 лет. В худшем случае ошибка может спровоцировать появление в программах вечных циклов, которые вызовут аварийное завершение работы.

Но в зону риска бага Y2038 попадают:

• файловые системы, использующие 32 бита для представления времени;
• базы данных с 32-битными полями времени;
• программы на SQL, которые используют команды типа UNIX_TIMESTAMP();
• любые 32-разрядные устройства, например смартфоны, компьютеры, авиационные бортовые журналы, GPS-приёмники и банкоматы.

Если строить фантастические картины в духе паники прошлого столетия, то 19 января 2038 года самолёты начнут сбиваться с курса, на дорогах выстроятся многокилометровые пробки, банкоматы перестанут выдавать наличные, телефоны превратятся в бесполезные кирпичи и весь мир останется без интернета. Всё это звучит пугающе, но на самом деле инженеры уже начали решать проблему Y2038.