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

Ошибка в программном обеспечении компьютера, произошедшая в 2038 году

Анимированное изображение ошибки в действии. Ошибка переполнения произойдет в 03:14:08 UTC 19 января 2038 года.

Проблема 2038 года ( также известная как Y2038 , ^[1] Y2K38 , супербактерия Y2K38 или Эпохалипс ^{[2] [3]} ) — это проблема вычисления времени , из-за которой некоторые компьютерные системы не могут отображать время после 03:14:07 UTC 19 января 2038 года.

Проблема существует в системах, которые измеряют время Unix — количество секунд, прошедших с эпохи Unix (00:00:00 UTC 1 января 1970 года) — и хранят его в виде 32-битного целого числа со знаком . Тип данных способен представлять целые числа только в диапазоне от −(2 ³¹ ) до 2 ³¹  − 1 , то есть самое позднее время, которое может быть правильно закодировано, составляет 2 ³¹  − 1 секунд после эпохи (03:14:07 UTC 19 января 2038 года). Попытка увеличения до следующей секунды (03:14:08) приведет к переполнению целого числа , установив его значение в −(2 ³¹ ), что системы будут интерпретировать как 2 ³¹ секунды до эпохи (20:45:52 UTC 13 декабря 1901 года). Задача по своей сути похожа на задачу 2000 года , разница лишь в том, что в задаче 2000 года речь идет о числах с основанием 10 , тогда как в задаче 2038 года речь идет о числах с основанием 2 .

Аналогичные ограничения по хранению будут достигнуты в 2106 году , когда системы, хранящие время Unix как беззнаковое (а не знаковое) 32-битное целое число, переполнятся 7 февраля 2106 года в 06:28:15 UTC.

Компьютерные системы, использующие время для критических вычислений, могут столкнуться с фатальными ошибками, если проблема 2038 года не будет решена. Некоторые приложения, использующие будущие даты, уже столкнулись с этой ошибкой. ^{[4] [5]} Наиболее уязвимыми являются те системы, которые обновляются редко или никогда не обновляются, такие как устаревшие и встроенные системы . Современные системы и обновления программного обеспечения для устаревших систем решают эту проблему, используя 64-битные целые числа со знаком вместо 32-битных целых чисел, переполнение которых займет 292 миллиарда лет — примерно в 21 раз больше предполагаемого возраста Вселенной .

Причина

Многие компьютерные системы измеряют время и дату, используя время Unix , международный стандарт цифрового хронометража. Время Unix определяется как количество секунд, прошедших с 00:00:00 UTC 1 января 1970 года (произвольно выбранное время, основанное на создании первой системы Unix ), которое было названо эпохой Unix . ^[6]

Время Unix исторически кодировалось как 32-битное целое число со знаком , тип данных, состоящий из 32 двоичных цифр (бит), которые представляют собой целочисленное значение, при этом «со знаком» означает, что число может представлять как положительные, так и отрицательные числа, а также ноль; и обычно хранится в формате дополнения до двух . ^[a] Таким образом, 32-битное целое число со знаком может представлять только целочисленные значения от −(2 ³¹ ) до 2 ³¹  − 1 включительно. Следовательно, если для хранения времени Unix используется 32-битное целое число со знаком, то самое позднее время, которое может быть сохранено, составляет 2 ³¹  − 1 (2 147 483 647) секунд после эпохи, что составляет 03:14:07 во вторник, 19 января 2038 года. ^[7] Системы, которые пытаются увеличить это значение еще на одну секунду до 2 ³¹ секунды после эпохи (03:14:08), будут страдать от целочисленного переполнения , непреднамеренно переворачивая бит знака, чтобы указать отрицательное число. Это изменяет целочисленное значение на −(2 ³¹ ), или 2 ³¹ секунды до эпохи, а не после , что системы будут интерпретировать как 20:45:52 в пятницу, 13 декабря 1901 года. Отсюда системы продолжат отсчет вверх, к нулю, а затем снова вверх через положительные целые числа. Поскольку многие компьютерные системы используют вычисления времени для выполнения критических функций, ошибка может привести к серьезным проблемам.

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

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

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

Встроенные системы

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

Многие транспортные системы от самолетов до автомобилей широко используют встроенные системы. В автомобильных системах это может включать антиблокировочную тормозную систему (ABS), электронную систему контроля устойчивости (ESC/ESP), систему контроля тяги (TCS) и автоматический полный привод ; самолеты могут использовать инерциальные системы наведения и GPS-приемники . ^[b] Другое важное применение встроенных систем — в коммуникационных устройствах, включая мобильные телефоны и устройства с доступом в Интернет (например, маршрутизаторы , беспроводные точки доступа , IP-камеры ), которые полагаются на хранение точного времени и даты и все чаще базируются на операционных системах типа Unix. Например, проблема Y2038 приводит к тому, что некоторые устройства под управлением 32-разрядной версии Android выходят из строя и не перезапускаются при изменении времени на эту дату. ^[8]

Однако это не означает, что все встроенные системы будут страдать от проблемы Y2038, поскольку многим таким системам не требуется доступ к датам. Для тех, которым требуется, те системы, которые отслеживают только разницу между временем/датами, а не абсолютным временем/датами, по характеру вычислений не испытают серьезной проблемы. Это касается автомобильной диагностики, основанной на законодательных стандартах, таких как CARB ( California Air Resources Board ). ^[9]

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

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

Решения

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

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

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

Реализованные решения

• Начиная с версии Ruby 1.9.2 (выпущенной 18 августа 2010 г.), ошибка с 2038 годом исправлена ^​​[16] путем сохранения времени в виде 64-битного целого числа со знаком на системах с 32-битной архитектурой time_t. ^[17]
• Начиная с версии NetBSD 6.0 (выпущенной в октябре 2012 года), операционная система NetBSD использует 64-бит time_tкак для 32-битной, так и для 64-битной архитектуры. Приложения, скомпилированные для более старой версии NetBSD с 32-битной архитектурой, time_tподдерживаются через уровень двоичной совместимости, но такие старые приложения по-прежнему будут страдать от проблемы Y2038. ^[18]
• OpenBSD , начиная с версии 5.5, выпущенной в мае 2014 года, также использует 64-бит time_tдля 32-битной и 64-битной архитектур. В отличие от NetBSD , здесь нет слоя двоичной совместимости. Поэтому приложения, ожидающие 32-бит time_t, и приложения, использующие что-либо отличное от time_tдля хранения значений времени, могут выйти из строя. ^[19]
• Linux изначально использовал 64-бит time_tтолько для 64-битных архитектур; чистый 32-битный ABI не был изменен из-за обратной совместимости. ^[20] Начиная с версии 5.6 2020 года, 64-бит time_tподдерживается и на 32-битных архитектурах. Это было сделано в первую очередь ради встраиваемых систем Linux . ^[21]
• Библиотека GNU C начиная с версии 2.34 (выпущена в августе 2021 г.) добавила поддержку использования 64-бит time_tна 32-битных платформах с соответствующими версиями Linux. Эту поддержку можно активировать, определив макрос препроцессора _TIME_BITSпри 64компиляции исходного кода. ^[22]
• FreeBSD использует 64-битную time_tархитектуру для всех 32-битных и 64-битных архитектур, за исключением 32-битной i386, которая вместо этого использует знаковую 32-битную архитектуру time_t. ^[23]
• x32 ABI для Linux (определяющий среду для программ с 32-битными адресами, но работающих на процессоре в 64-битном режиме) использует 64-битную time_t. Поскольку это была новая среда, не было необходимости в особых мерах предосторожности для совместимости. ^[20]
• Сетевая файловая система версии 4 определила свои поля времени как struct nfstime4 {int64_t seconds; uint32_t nseconds;}с декабря 2000 года. ^[24] Версия 3 поддерживает беззнаковые 32-битные значения как struct nfstime3 {uint32 seconds; uint32 nseconds;};. ^[25] Значения больше нуля для поля секунд обозначают даты после 0-го часа, 1 января 1970 года. Значения меньше нуля для поля секунд обозначают даты до 0-го часа, 1 января 1970 года. В обоих случаях поле nseconds (наносекунд) должно быть добавлено к полю секунд для окончательного представления времени.
• Файловая система ext4 при использовании с размерами inode более 128 байт имеет дополнительное 32-битное поле на временную метку, из которых 30 бит используются для наносекундной части временной метки, а остальные 2 бита используются для расширения диапазона временной метки до 2446 года. ^[26]
• Файловая система XFS , начиная с Linux 5.10, имеет дополнительную функцию «больших временных меток», которая расширяет диапазон временных меток до 2486 года. ^[27]
• В то время как собственные API OpenVMS могут поддерживать временные метки до 31 июля 31086 года, ^[28] библиотека времени выполнения C (CRTL) использует 32-битные целые числа для time_t. ^[29] В рамках работы по обеспечению соответствия требованиям Y2K, которая была проведена в 1998 году, CRTL была изменена для использования беззнаковых 32-битных целых чисел для представления времени; что расширило диапазон time_tдо 7 февраля 2106 года. ^[30]
• PostgreSQL , начиная с версии 7.2, выпущенной 4 февраля 2002 г., хранит временную метку БЕЗ ЧАСОВОГО ПОЯСА как 64-битную. ^{[31] [ проверка не удалась ]} Предыдущие версии уже хранили временную метку как 64-битную. ^{[ необходима ссылка ]}
• Начиная с версии MySQL 8.0.28, выпущенной в январе 2022 года, функции FROM_UNIXTIME(), UNIX_TIMESTAMP()и CONVERT_TZ()обрабатывают 64-битные значения на платформах, которые их поддерживают. Сюда входят 64-битные версии Linux, macOS и Windows. ^{[32] [33]} В более старых версиях встроенные функции, такие как , UNIX_TIMESTAMP()будут возвращать 0 после 03:14:07 UTC 19 января 2038 года. ^[34]
• Начиная с версии MariaDB 11.5.1, выпущенной в мае 2024 года, тип данных TIMESTAMPи функции FROM_UNIXTIME(), UNIX_TIMESTAMP()и CONVERT_TZ()обрабатывают беззнаковые 32-битные значения в 64-битных версиях Linux, macOS и Windows. ^[35] Это расширило диапазон до 2106-02-07 06:28:15 и позволило пользователям хранить такие значения временных меток в таблицах, не изменяя структуру хранилища и, таким образом, оставаясь полностью совместимыми с существующими пользовательскими данными.
• Начиная с Visual C++ 2005, CRT использует 64-битную версию, time_tесли не _USE_32BIT_TIME_Tопределен макрос препроцессора. ^[36] Однако сам API Windows не подвержен ошибке 2038 года, поскольку Windows внутренне отслеживает время как количество 100-наносекундных интервалов с 1 января 1601 года в 64-битном знаковом целом числе, которое не переполнится до 30 828 года . ^[37]

Смотрите также

• В разделе «Ошибки форматирования и хранения времени» перечислены другие похожие проблемы, часто вызываемые переносом, аналогичными причине этой проблемы с 2038 годом.
• По совпадению, смена номера недели GPS произойдет позднее в 2038 году по другой причине, нежели эта проблема 2038 года.

Примечания

1. Если не указано иное, все числа, приведенные в этой статье, были получены с использованием дополнения до двух для арифметики целых чисел со знаком.
2. GPS сталкивается с собственной проблемой переполнения счетчика времени, известной как сброс номера недели GPS .

Ссылки

1. «Является ли проблема 2038 года новой ошибкой Y2K?». The Guardian . 17 декабря 2014 г. Архивировано из оригинала 25 января 2022 г. Получено 11 октября 2018 г.
2. Бергманн, Арнд (6 февраля 2020 г.). «Конец эпохи». Линаро. Архивировано из оригинала 7 февраля 2020 г. Получено 13 сентября 2020 г.
3. Вагенсейл, Пол (28 июля 2017 г.). «Цифровой „Epochalypse“ может привести мир к остановке». Tom's Guide . Архивировано из оригинала 29 ноября 2021 г. Получено 13 сентября 2020 г.
4. "Будущее впереди". 28 июня 2006 г. Архивировано из оригинала 28 ноября 2006 г. Получено 19 ноября 2006 г.
5. Странная проблема «утечки памяти» в AOLserver 3.4.2/3.x Архивировано 4 января 2010 г. на Wayback Machine 12 мая 2006 г.
6. "Epoch Time". unixtutoria . 15 марта 2019 г. Архивировано из оригинала 13 апреля 2023 г. Получено 13 апреля 2023 г.
7. Диомидис Спинеллис (2006). Качество кода: перспектива открытого исходного кода. Эффективная серия разработки программного обеспечения в Safari Books Online (иллюстрированное издание). Adobe Press . стр. 49. ISBN 978-0-321-16607-4.
8. "ZTE Blade под управлением Android 2.2 имеет 2038 проблем". Архивировано из оригинала 19 мая 2022 года . Получено 20 ноября 2018 года .
9. "Методы / процедуры испытаний ARB". ARB.ca.gov . Калифорнийский совет по воздушным ресурсам . Архивировано из оригинала 18 ноября 2016 года . Получено 12 сентября 2013 года .
10. "ЧЕРНОВИК: Y2038 Proofness Design". Архивировано из оригинала 21 сентября 2019 г. Получено 25 мая 2024 г.
11. «Когда на самом деле заканчивается 64-битный Unix time_t?». Архивировано из оригинала 23 сентября 2022 г. Получено 24 сентября 2022 г.
12. Фелтс, Боб (17 апреля 2010 г.). «Конец времени». Stablecross.com . Архивировано из оригинала 11 октября 2012 г. Получено 19 марта 2012 г.
13. "Unununium Time". Архивировано из оригинала 8 апреля 2006 года . Получено 19 ноября 2006 года .
14. Sun Microsystems. "Java API documentation for System.currentTimeMillis()". Архивировано из оригинала 30 сентября 2017 г. Получено 29 сентября 2017 г.
15. "TAI64". Архивировано из оригинала 26 сентября 2012 года . Получено 4 сентября 2012 года .
16. "Ruby 1.9.2 is released". 18 августа 2010 г. Архивировано из оригинала 8 апреля 2022 г. Получено 1 апреля 2022 г.
17. "time.c: использовать 64-битную арифметику даже на платформах с 32-битным VALUE". GitHub . Архивировано из оригинала 3 ноября 2023 г. Получено 3 ноября 2023 г.
18. "Annoncing NetBSD 6.0". 17 октября 2012 г. Архивировано из оригинала 15 января 2016 г. Получено 18 января 2016 г.
19. "OpenBSD 5.5 выпущен (1 мая 2014 г.)". 1 мая 2014 г. Архивировано из оригинала 22 декабря 2015 г. Получено 18 января 2016 г.
20. Jonathan Corbet (14 августа 2013 г.). "Pondering 2038". LWN.net . Архивировано из оригинала 4 марта 2016 г. . Получено 9 марта 2016 г. .
21. "LKML: Arnd Bergmann: [GIT PULL] y2038: изменения ядра, драйвера и файловой системы". lkml.org . Архивировано из оригинала 14 февраля 2020 г. . Получено 30 января 2020 г. .
22. О'Донелл, Карлос (2 августа 2021 г.). «Библиотека GNU C версии 2.34 уже доступна». Sourceware . Архивировано из оригинала 30 апреля 2024 г. . Получено 30 апреля 2024 г. .
23. "arch". www.freebsd.org . Архивировано из оригинала 26 сентября 2018 . Получено 26 сентября 2018 .
24. Хейнс, Томас; Новек, Дэвид, ред. (март 2015 г.). «Структурированные типы данных». Протокол сетевой файловой системы (NFS) версии 4. раздел 2.2. doi : 10.17487/RFC7530 . RFC 7530.
25. Штаубах, Питер; Павловски, Брайан; Каллаган, Брент (июнь 1995 г.). "NFS Version 3 Protocol Specification" . Получено 25 мая 2024 г. .
26. "ext4 Data Structures and Algorithms". Архивировано из оригинала 13 сентября 2022 г. Получено 13 сентября 2022 г.
27. Майкл Ларабель (15 октября 2020 г.). «Файловая система XFS с Linux 5.10 переводит проблему 2038 года в 2486 год». Phoronix . Архивировано из оригинала 13 сентября 2022 г. . Получено 13 сентября 2022 г. .
28. «Почему среда, 17 ноября 1858 года является базовым временем для OpenVMS (VAX VMS)?». Стэнфордский университет . 24 июля 1997 г. Архивировано из оригинала 24 июля 1997 г. Получено 8 января 2020 г.
29. "VSI C Run-Time Library Reference Manual for OpenVMS Systems" (PDF) . VSI. Ноябрь 2020 г. Архивировано из оригинала (PDF) 17 апреля 2021 г. Получено 17 апреля 2021 г.
30. "OpenVMS и год 2038". HP. Архивировано из оригинала 17 апреля 2021 г. Получено 17 апреля 2021 г.
31. "PostgreSQL Release 7.2". Январь 2012. Архивировано из оригинала 26 апреля 2024 года . Получено 25 апреля 2024 года .
32. "Что нового в MySQL 8.0". dev.mysql.com .
33. "Изменения в MySQL 8.0.28 (2022-01-18, Общая доступность)". dev.mysql.com . Архивировано из оригинала 8 декабря 2023 г. . Получено 14 мая 2024 г. .
34. "MySQL Bugs: #12654: 64-битная метка времени unix не поддерживается в функциях MySQL". bugs.mysql.com . Архивировано из оригинала 29 марта 2017 г. . Получено 28 марта 2017 г. .
35. «Примечания к выпуску MariaDB 11.5.1».
36. "История изменений Microsoft C/C++ 2003 - 2015". learn.microsoft.com . 25 мая 2023 г. . Получено 13 августа 2024 г. .
37. "About Time - Win32 apps". learn.microsoft.com . 7 января 2021 г. . Получено 13 августа 2024 г. .

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

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