Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Одно из возможных проявлений ошибки на конкретном компьютере: дата могла быть сброшена в 03:14:08 UTC 19 января 2038 года.

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

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

Последнее время , так как 1 января 1970 года , которые могут быть сохранены с помощью 32-разрядное целое число является 3:14:07 во вторник, 19 января 2038 (2 31 -1 = 2147483647 секунд после 1 января 1970 г.). [3]

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

Ранние проблемы [ править ]

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

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

Уязвимые системы [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

Метки времени протокола сетевого времени [ править ]

Протокол сетевого времени (NTP) имеет связанную проблему переполнения, которая сам по себе проявляется в 2036, а не 2038. 64-разрядные временные метки NTP , используемая состоит из 32-битной части за секунды и 32-битовую часть для дробной секунды, давая NTP шкалу времени, которая перемещается каждые 2 32 секунды (136 лет) и теоретическое разрешение 2-32 секунды (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 имеет поддержку Era Номер и Era Offset , что при правильном использовании должно помочь решению проблем с даты пролонгации. По словам Миллса , «64-битного значения дроби достаточно, чтобы определить количество времени, необходимое фотону для прохождения электрона со скоростью света. 64-битного значения секунды достаточно, чтобы обеспечить однозначное представление времени до тех пор, пока Вселенная не перестанет существовать. тусклый " [12] [примечание 2]

Возможные решения [ редактировать ]

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

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

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

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

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

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

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

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

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

См. Также [ править ]

  • Считается, что Deep Impact был утерян в то время, когда его внутренние часы достигли 2 32 100- миллисекундных интервалов (одна десятая секунда) с 2000 года, 11 августа 2013 года, 00:38:49 UTC.
  • Джон Титор , предполагаемый путешественник во времени, который иногда имеет отношение к проблеме
  • Ошибки форматирования и хранения времени
  • Время Unix
  • Проблема 10,000 года
  • Проблема 2000 года

Заметки [ править ]

  1. ^ У GPS есть собственная проблема переполнения счетчика времени, известная как перенос номера недели GPS .
  2. ^ 2 −64 секунды составляет около 54 зептосекунд или54 × 10 −21  с (свет прошел бы 16,26 пикометра, или примерно 0,31 × радиус Бора ), а 2 64 секунды - это около 585 миллиардов лет .

Ссылки [ править ]

  1. ↑ Бергманн, Арнд (6 февраля 2020 г.). «Конец эпохи» . Линаро.
  2. ^ Wagenseil, Павел (28 июля 2017). «Цифровой« Эпохалипсис »может остановить мир» . Руководство Тома .
  3. ^ Диомидис Спинеллис (2006). Качество кода: взгляд на открытый исходный код . Серия эффективных программных продуктов в Safari Books Online (иллюстрированный редактор). Adobe Press . п. 49. ISBN 978-0-321-16607-4.
  4. ^ «Будущее лежит впереди» . 28 июня 2006 . Проверено 19 ноября 2006 года .
  5. ^ Странная проблема "утечки памяти" в AOLserver 3.4.2 / 3.x 12 мая 2006 г.
  6. Перейти ↑ Fahey, Mike (21 января 2013 г.). «Бесконечные жизни в Candy Crush Saga - это не обман, это путешествие во времени» . Котаку .
  7. ^ "Является ли проблема 2038 года новой ошибкой 2000 года?" . Хранитель . 17 декабря 2014 . Проверено 11 октября 2018 года .
  8. ^ «Методы / процедуры испытаний ARB» . ARB.ca.gov . Калифорнийский совет по воздушным ресурсам .
  9. ^ «ZTE Blade под управлением Android 2.2 имеет 2038 проблем» . Проверено 20 ноября 2018 года .
  10. ^ «Ошибки MySQL: # 12654: 64-битная временная метка unix не поддерживается в функциях MySQL» . bugs.mysql.com .
  11. ^ "unix - Уязвима ли какая-либо версия OS X / macOS для проблемы 2038 года?" . Спросите другого . Проверено 12 октября 2019 .
  12. ^ Презентация семинара по цифровым системам Университета Делавэра Дэвида Миллса, 26 апреля 2006 г.
  13. ^ Войлок, Боб (17 апреля 2010). «Конец времени» . Stablecross.com . Проверено 19 марта 2012 года .
  14. ^ https://www.freebsd.org/cgi/man.cgi?arch
  15. ^ "Анонс NetBSD 6.0" . 17 октября 2012 . Проверено 18 января +2016 .
  16. ^ «OpenBSD 5.5 выпущен (1 мая 2014 г.)» . 1 мая 2014 . Проверено 18 января +2016 .
  17. ^ a b Джонатан Корбет (14 августа 2013 г.). «Размышляя до 2038 года» . LWN.net . Архивировано 4 марта 2016 года . Проверено 9 марта +2016 .
  18. ^ «LKML: Арнд Бергманн: [GIT PULL] y2038: изменения ядра, драйверов и файловой системы» . lkml.org . Проверено 30 января 2020 года .
  19. ^ Хейнс, Томас; Новек, Дэвид, ред. (Март 2015 г.). «Структурированные типы данных» . Протокол сетевой файловой системы (NFS) версии 4 . сек. 2.2. DOI : 10,17487 / RFC7530 . RFC 7530 .
  20. ^ "Unununium Time" . Архивировано из оригинала 8 апреля 2006 года . Проверено 19 ноября 2006 года .
  21. ^ Sun Microsystems. «Документация Java API для System.currentTimeMillis ()» . Проверено 29 сентября 2017 года .
  22. ^ "TAI64" .

Внешние ссылки [ править ]

  • Дизайн доказательства устойчивости Y2038 glibc вики
  • Запись в How Stuff Works
  • Часто задаваемые вопросы о проекте 2038
  • Критические и знаменательные даты 2038 г.
  • Безопасная для 2038 года замена time.h в 32-битных системах
  • Баранюк, Крис (5 мая 2015 г.). «Номерной глюк, который может привести к катастрофе» . BBC Future .
  • Клеветт, Джеймс. «2 147 483 647 - Конец времен [Unix]» . Numberphile . Брэди Харан . Архивировано из оригинального 22 мая 2017 года . Проверено 7 апреля 2013 года .