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

редактировать
ошибка программного обеспечения компьютера с 32-битным системным временем Одно из возможных проявлений ошибки на конкретном компьютере: дата может быть сброшена в 03:14:08 UTC 19 января 2038 года.

Проблема года 2038 (также называемая Y2038, Epochalypse, Y2k38 или Unix Y2K) относится к представлению времени во многих цифровых системах как количество секунд, прошедших с 00:00:00 UTC 1 января 1970 и сохраняющее его как 32-битное целое число со знаком. Такие реализации не могут кодировать время после 03:14:07 UTC 19 января 2038 года. Подобно проблеме 2000 года, проблема 2038 года вызвана недостаточной емкостью, используемой для представления времени.

Содержание

  • 1 Причина
  • 2 Ранние проблемы
  • 3 Уязвимые системы
  • 4 Структуры данных с проблемами времени
  • 5 Временные метки сетевого протокола времени
  • 6 Возможные решения
  • 7 См. Также
  • 8 Примечания
  • 9 Ссылки
  • 10 Внешние ссылки

Причина

Последнее время с 1 января 1970 г., которое может быть сохранено с использованием 32-битного целого числа со знаком - 03:14:07 во вторник, 19 января 2038 г. (2-1 = 2 147 483 647 секунд после 1 января 1970 г.).

Программы, которые пытаются увеличить время после этой даты, будут вызывать внутреннее сохранение значения как очень большое отрицательное число, которое эти системы будут интерпретировать как возникшее в 20:45:52 в пятницу, 13 декабря 1901 года, а не 19 января 2038 года. Это вызвано целочисленным переполнением, в течение которого счетчик работает из используемых цифровых битов и вместо этого меняет знаковый бит. Это сообщает о максимально отрицательном числе и продолжает отсчет до нуля, а затем снова до положительных целых чисел. Ошибочные вычисления в таких системах могут вызвать проблемы для пользователей и других сторонних организаций.

Программы, работающие с будущими датами, раньше начнут сталкиваться с проблемами; например, программу, которая работает с датами на 10 лет вперед, необходимо будет исправить не позднее 19 января 2028 года.

Ранние проблемы

В мае 2006 года появились сообщения о раннем проявлении проблемы Y2038 в программном обеспечении AOLserver. Программное обеспечение было разработано с использованием kludge для обработки запросов к базе данных, которые не должны "никогда" истекать по тайм-ауту. Вместо того, чтобы специально обрабатывать этот особый случай, первоначальный дизайн просто указывал произвольную дату тайм-аута в будущем. В конфигурации по умолчанию для сервера указано, что время ожидания запроса должно истечь через один миллиард секунд. Один миллиард секунд (приблизительно 32 года) после 01:27:28 UTC 13 мая 2006 года превышает дату отсечения 2038 года. Таким образом, по прошествии этого времени вычисление тайм-аута переполнилось и вернуло дату, которая фактически была в прошлом, что привело к сбою программного обеспечения. Когда проблема была обнаружена, операторы AOLServer должны были отредактировать файл конфигурации и установить более низкое значение тайм-аута.

Игроки игр или приложений, которые запрограммированы на введение периодов ожидания, сталкиваются с этой проблемой, когда Игроки пытаются обойти период ожидания, установив дату на своих устройствах на дату, прошедшую 19 января 2038 года, но не могут этого сделать, поскольку используется 32-битный формат времени Unix.

Уязвимые системы

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

Многие транспортные системы от полета до автомобилей используют встроенные системы широко. В автомобильных системах это может включать антиблокировочную тормозную систему (ABS), электронный контроль устойчивости (ESC / ESP), контроль тяги (TCS) и автоматический полный привод; самолет может использовать инерциальные системы наведения и приемники GPS. Однако это не означает, что все эти системы будут страдать от проблемы Y2038, поскольку многие такие системы не требуют доступа к датам. Для тех, кто это делает, системы, которые отслеживают только разницу между временем / датой, а не абсолютное время / дату, по характеру расчета не будут испытывать серьезных проблем. Это относится к автомобильной диагностике, основанной на законодательных стандартах, таких как CARB (California Air Resources Board ).

Еще одно важное применение встроенных систем - в устройствах связи, включая сотовые телефоны и интернет-устройства (маршрутизаторы, точки беспроводного доступа и т. Д.)..), которые полагаются на хранение точного времени и даты и все чаще основываются на UNIX-подобных операционных системах. Например, проблема Y2038 приводит к аварийному завершению работы некоторых устройств, работающих под управлением 32-разрядной версии Android, и невозможности перезапуска, когда время изменено на эту дату.

Несмотря на современное 18–24-месячное обновление технологий компьютерных систем, встроенные системы рассчитаны на срок службы машины, в которой они являются компонентом. Вполне возможно, что некоторые из этих систем могут все еще использоваться в 2038 году. Может быть непрактично или, в некоторых случаях, невозможно обновить программное обеспечение, работающее на этих системах, что в конечном итоге потребует замены, если 32-разрядные ограничения должны быть исправлены.

MySQL база данных встроенные функции, такие как UNIX_TIMESTAMP (), вернут 0 после 03:14:07 UTC 19 января 2038 года.

Раннее Mac OS X версии подвержены проблеме 2038 года.

Структуры данных с проблемами времени

Многие структуры данных, используемые сегодня, имеют 32-битные представления времени, встроенные в их структуру. Полный список этих структур данных практически невозможно составить, но есть хорошо известные структуры данных, которые имеют проблему времени Unix:

  • файловые системы (многие файловые системы используют только 32 бита для представления времени в inodes )
  • форматы двоичных файлов (в которых используются 32-битные поля времени)
  • базы данных (с 32-битными полями времени)
  • языки запросов к базам данных, например SQL с UNIX_TIMESTAMP ()-подобные команды

Примеры систем, использующих структуры данных, которые могут содержать 32-битные представления времени, включают:

  • встроенный завод, подсистемы управления и мониторинга нефтеперерабатывающего завода
  • различные медицинские устройства
  • различные военные устройства

Любая система, использующая структуры данных, содержащие 32-битные представления времени, будет представлять опасность. Степень риска зависит от режима отказа.

Протокол сетевого времени отметки времени

Протокол сетевого времени (NTP) имеет связанную проблему переполнения, которая проявляется в 2036 году, а не в 2038 году. Временные метки t, используемые NTP, состоят из 32-битной части для секунд и 32-битной части для дробной секунды, что дает NTP шкалу времени, которая перемещается по каждые 2 секунды (136 лет) и теоретическое разрешение 2 секунды (233 пикосекунды). NTP использует эпоху 1 января 1900 года. Первое обновление происходит в 2036 году, до проблемы 2038 года в UNIX.

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

  1. Они получают дату 1900-01-01 00: 00: 00UTC, а не 2036-02-07 06:28:15 (плюс-минус несколько дополнительных секунд) как новое время.
  2. Когда клиент пытается принять это время и сохранить его в формате времени UNIX, как это делают многие встроенные системы, он потерпит неудачу, потому что время UNIX начинается с 13 декабря 1901 года (32-битное целое число со знаком) или 1 января 1970 г. (32-битное целое число без знака).

Это означает, что для NTP переключение будет невидимым для большинства работающих систем, поскольку они будут иметь правильное время с очень малым допуском. Однако системы, которые запускаются, должны знать дату в пределах не более 68 лет. С учетом большой допустимой ошибки не ожидается, что это будет слишком обременительным требованием. Один из предлагаемых способов - установить часы не раньше даты сборки системы или даты выпуска текущей версии программного обеспечения NTP. Во многих системах используются аппаратные часы с батарейным питанием, чтобы избежать этой проблемы.

Тем не менее, будущие версии NTP могут расширить представление времени до 128 бит: 64 бита для второй и 64 бита для дробной секунды. Текущий формат NTP4 поддерживает номера эры и смещение эры, которые при правильном использовании должны помочь решить проблемы с переносом даты. По словам Миллса, «64-битного значения дроби достаточно, чтобы определить количество времени, которое требуется фотону, чтобы пройти электрон со скоростью света. 64-битная секунда значения достаточно, чтобы обеспечить однозначное представление времени, пока вселенная не потускнеет."

Возможные решения

Универсального решения проблемы 2038 года не существует. Например, в языке C, любое изменение определения типа данных time_t приведет к проблемам совместимости кода в любом приложении, в котором представления даты и времени зависят от характера 32-битного целого числа time_tсо знаком. Например, изменение time_tна 32-битное целое число без знака, которое расширит диапазон до 2106 (в частности, 06:28:15 UTC в воскресенье, 7 февраля 2106 г.), может отрицательно повлиять на программы, которые хранят, извлекают или обрабатывают даты до 1970 г., поскольку такие даты представлены отрицательными числами. Увеличение размера time_t <Тип 10> на 64-битный в существующей системе вызовет несовместимые изменения в компоновке структур и бинарном интерфейсе функций.

Большинство операционных систем, предназначенных для работы на 64-битном оборудовании, уже используют 64-битные time_tцелые числа со знаком. Использование 64-битного значения со знаком вводит новую дату переноса, которая более чем в двадцать раз превышает предполагаемый возраст вселенной : примерно 292 миллиарда лет с настоящего момента. Возможность выполнять вычисления по датам ограничена тем фактом, что tm_yearиспользует 32-битное целое число со знаком, начиная с 1900 года. Это ограничивает год максимумом 2147485477 (2147483647 + 1900).

FreeBSD использует 64-битный time_tдля всех 32-битных и 64-битных архитектур, кроме 32-битной i386, которая вместо этого используется 32-битное time_tбез знака.

Начиная с NetBSD версии 6.0 (выпущенной в октябре 2012 г.), операционная система NetBSD использует 64-битный time_tдля 32-битной и 64-битной архитектур. Приложения, которые были скомпилированы для более ранней версии NetBSD с 32-битным time_t, поддерживаются через уровень двоичной совместимости, но такие старые приложения по-прежнему будут страдать от проблемы 2038 года.

OpenBSD с версии 5.5, выпущенный в мае 2014 года, также использует 64-битный time_tкак для 32-битной, так и для 64-битной архитектуры. В отличие от NetBSD, здесь нет уровня двоичной совместимости. Следовательно, приложения, ожидающие 32-битного time_t, и приложения, использующие что-либо отличное от time_tдля хранения значений времени, могут выйти из строя.

Linux изначально использовал 64-битный time_tтолько для 64-битных архитектур; чистый 32-битный ABI не был изменен из-за обратной совместимости. Начиная с версии 5.6, 64-битный time_tтакже поддерживается на 32-битных архитектурах. Это было сделано в первую очередь для встроенных систем Linux.

x32 ABI для Linux (который определяет среду для программ с 32 -битные адреса, но процессор работает в 64-битном режиме) использует 64-битное time_t. Поскольку это была новая среда, особых мер предосторожности в отношении совместимости не требовалось.

Сетевая файловая система версии 4 определила свои поля времени как struct nfstime4 {int64_t seconds; uint32_t nseconds;}с декабря 2000 года. Значения больше нуля для поля секунд обозначают даты после 0-часового 1 января 1970 г. Значения меньше нуля для поля секунд обозначают даты до 0-часового 1 января., 1970. В обоих случаях поле nseconds (наносекунды) должно быть добавлено к полю секунд для окончательного представления времени.

Были внесены альтернативные предложения (некоторые из которых уже используются), такие как сохранение либо миллисекунд, либо микросекунд с эпохи (обычно либо 1 января 1970 г., либо 1 января 2000 г.) в виде 64-битного целого числа со знаком, обеспечивающего минимальный диапазон 300 000 лет при микросекундном разрешении. В частности, использование Java повсюду 64-битных длинных целых чисел для представления времени как «миллисекунд с 1 января 1970 года» будет правильно работать в течение следующих 292 миллионов лет. Другие предложения для новых представлений времени обеспечивают другую точность, диапазоны и размеры (почти всегда больше 32 бит), а также решают другие связанные проблемы, такие как обработка дополнительных секунд. В частности, TAI64 является реализацией стандарта Международного атомного времени (TAI), текущего международного стандарта реального времени для определения секунды и системы отсчета.

См. Также

Примечания

Ссылки

Внешние ссылки

Последняя правка сделана 2021-06-22 11:38:14
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте