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

Материал из Викиреальностя
Перейти к: навигация, поиск

Проблема 2038 года в вычислительной технике — ожидаемый 19 января 2038 года сбой в работе 32-битных компьютеров с измерением времени в формате POSIX (Unix-time).

Содержание

[править] Суть

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

В современных вычислительных системах, в том числе в самых распространённых на первое десятилетие XXI века компьютерах под управлением операционных систем Microsoft Windows, Apple Mac OS/iOS и Unix-подобных OS (Linux, Fedora, BSD, etc.), используется фон-Неймановская архитектура и язык C[1]. В числе библиотек последнего есть заголовочный файл <time.h>, в котором определёна переменная отсчёта времени time_t типа signed int (стандартное целое число со знаком, в 32-битных и 64-битных системах эквивалентно 32 битам), в которую при её инициализации (при выполнении программ) записывается число секунд, прошедших с момента начала «эпохи Unix» (00:00:00 01.01.1970 (GMT/GDT/UTC)), после чего переменная начинает увеличиваться на 1 после каждого тика микропроцессора, подающего сигналы с частотой 1 Гц (1 колебание/тик в секунду). Данный способ отсчёта времени используется с 1988 года, когда был принят стандарт POSIX (IEEE Std 1003.1-1988) и стали вводиться 16/32-битные архитектуры.

Основная проблема такого формата состоит в том, что значение числа секунд не может превысить положительного двоичного числа из 31 единицы (2147483647, самый старший бит используется для обозначения знака). В итоге значение переменной (timestamp) ограничено сверху временной точкой 03:14:07 19 января 2038 года (UTC). В 03:14:08 переменная примет двоичное значение 1000 0000 0000 0000 0000 0000 0000 0000, что будет интерпретировано как отрицательное целое число -2147483648. Аппаратно-программное обеспечение, выполнив смещение даты от начала «эпохи Unix», выдаст дату 20:45:52, 13 декабря 1901 года (GMT/GDT/UTC) и (по идее) будет считать время от этой даты до полуночи на 1 января 1970 года, когда произойдёт обнуление (породив в результате закольцованность). Большинство систем (ведущие визуальный учёт времени с 1 января 1970 года) выдадут на такой результат ошибку (пользователь 32-битной машины с Mandriva Lunix получит в комплекте с датой из прошлого повисшие «кеды»).

Некотрые компьютеры, впрочем, «уведомлены» о возможности такого исхода: на некоторых машинах используется проверка старшего бита. И если он становится равным единице, то система сбрасывает его в ноль. В этом случае откат времени произойдёт не в начало XX века, а в 1970 год, что, впрочем, не решит проблему[1].

[править] Решение

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

  • переход на формат времени unsigned int лишит машины возможности делать разностные расчёты времени (для отматывания времени назад используются инкременты на отрицательные смещения)
  • ввод же 64-битного целого числа со знаком нарушит совместимость кода, сделанного на машинах с использованием этого формата для старых машин.

С переходом на 64-битную архитектуру (который по расчётам многих аналитиков должен полностью завершиться задолго до 2038 года) этот сценарий конца света становится неактуальным (вернее, переносится на 15:30:08 4 декабря 292277026596 года, выдав заодно ещё более эпичную закольцованность в 584+ миллиарда лет). Однако есть вероятность того, что компьютеры с 32-битной архитектурой «доживут» до 2038 года, поскольку выпускаются и поныне, а некоторые аппараты, запущенные в конце 80-х-середине 90-х, работают и поныне, что сохраняет актуальность проблемы (модернизация не вездесуща).

[править] Интересные факты

  • «Путешественник во времени» Джон Тайтор упоминал в одном из своих сообщений на форумах, что прибыл в прошлое (в 1970-е годы), чтобы доставить в будущее компьютер, который поможет разрешить эту проблему.
  • В аналогичной ситуации оказался YouTube: самое популярное видео в интернете — клип «Gangnam Style» южнокорейского исполнителя Psy — вызвало переполнение числа просмотров. Когда количество просмотров достигло 2 147 483 647, счётчик просто перестал работать. Программистам Google пришлось его переписывать. Починили с большим заделом — теперь допустимое количество просмотров составляет 9 223 372 036 854 775 808 (более 9 квинтиллионов)[2].

[править] Примечания