В информатике ограничения типов данных и программные ошибки могут вызывать ошибки в вычислении или отображении времени и даты . Чаще всего это проявления арифметического переполнения , но также могут быть результатом других проблем. Наиболее известным последствием этого типа является проблема Y2K , но существует много других важных дат или времен, которые вызывали или будут вызывать проблемы в зависимости от различных недостатков программирования.
5 января 1975 года 12-битное поле, которое использовалось для дат в операционной системе TOPS-10 для компьютеров DEC PDP-10 , переполнилось в результате ошибки, известной как «DATE75». Значение поля вычислялось путем взятия количества лет с 1964 года, умножения на 12, добавления количества месяцев с января, умножения на 31 и добавления количества дней с начала месяца; подстановка в это дает 4 января 1975 года, что, следовательно, является последней кодируемой датой. Патч «DATE-75» сдвинул последнюю кодируемую дату на 1 февраля 2052 года, сделав дату переполнения 2 февраля 2052 года, используя 3 запасных бита из других полей в метаданных файловой системы , но это иногда вызывало проблемы с программным обеспечением, которое использовало эти биты для своих собственных целей. Некоторое программное обеспечение могло поддерживать использование одного дополнительного бита для даты, но имело проблемы с дополнительными битами, что могло привести к некоторым ошибкам 9 января 1986 года. [1] [2] [3] [4]
Операционная система Digital Equipment Corporation OS/8 для компьютера PDP-8 использовала только три бита для обозначения года, что соответствовало годам с 1970 по 1977. [5]
Это было признано, когда была разработана операционная система COS-310 , и даты стали записываться по-другому. [6]
Несколько игр Sierra Entertainment, выпущенных для Classic Mac OS, начали зависать при запуске 18 сентября 1993 года. Проблема в версии Creative Interpreter (Mac SCI) от Sierra для Mac приводила к «зависанию» игры при попытке обработать задержку из-за проблемы, связанной с переполнением. Mac SCI пытался использовать дату, чтобы определить, как долго должна длиться задержка, получая текущее время в секундах с 1 января 1904 года, эпохи Macintosh, и делил на 12 часов. Деление обрабатывалось Motorola 68000 и не происходило, если из-за деления обнаруживалось переполнение, но Mac SCI продолжал работать независимо, как если бы деление произошло, в конечном итоге приводя к тому, что задержка в одну секунду рассматривалась как задержка в 18 часов и так далее. Sierra выпустила патч под названием MCDATE, который решил проблему почти на 14 лет. [7] [8]
Часы домена /ОС , основанные на количестве 4-микросекундных единиц, появившихся с 1 января 1980 года, превысили 47 бит 2 ноября 1997 года, сделав неиспользуемые системы непригодными для использования. [9]
В последние несколько месяцев перед 2000 годом произошли еще два события, связанных с датами, которые получили меньшую огласку, чем надвигавшаяся тогда проблема Y2K.
Даты GPS выражаются как номер недели и номер дня недели, причем номер недели передается как десятибитное значение . Это означает, что каждые 1024 недели (около 19,6 лет) после воскресенья 6 января 1980 года ( эпоха GPS ) дата снова сбрасывается на эту дату; это произошло в первый раз в 23:59:47 21 августа 1999 года, [10] второй раз в 23:59:42 UTC 6 апреля 2019 года и повторится 20 ноября 2038 года. [11] Чтобы решить эту проблему, модернизированные навигационные сообщения GPS используют 13-битное поле, которое повторяется только каждые 8192 недели (157 лет) и не вернется к нулю до 2137 года. [12]
Многие устаревшие программы или наборы данных использовали "9/9/99" как мошенническое значение для указания неразрешенной даты или как терминатор для указания отсутствия дальнейших данных в наборе. Это приводило к сбою многих систем при достижении фактической даты, которую это представляет, 9 сентября 1999 года. [10]
Термин «проблема 2000 года» или просто Y2K относится к потенциальным компьютерным ошибкам, связанным с форматированием и хранением календарных данных для дат в 2000 году и после него. Многие программы представляли четырехзначные годы только с двумя последними цифрами, что делало 2000 год неотличимым от 1900 года. Неспособность компьютерных систем правильно различать даты могла привести к краху всемирной инфраструктуры для отраслей, зависящих от компьютеров.
Для приложений, требующих вычисления года рождения (или другого прошедшего года), такой алгоритм уже давно используется для решения проблемы 1900 года , но он не распознает людей старше 100 лет .
Системы, которые использовали строку из девяти цифр для записи времени в секундах с эпохи Unix, имели проблемы с отчетом о времени за пределами одной миллиардной секунды после эпохи 9 сентября 2001 года в 01:46:40 («биллениум»). Проблемы не были широко распространены. [13]
Игры Sierra Entertainment для Classic Mac OS, которые были пропатчены программой MCDATE или выпущены позже со встроенным патчем, начали зависать 28 мая 2007 года. Как и в случае с проблемой 1993 года, это было связано с проблемой в Mac SCI при попытке использовать дату для определения длительности задержки. Программы с патчем MCDATE зависают, потому что Mac SCI берет текущее количество секунд с эпохи Macintosh 1 января 1904 года, вычитает из этого 432 000 000 секунд, а затем делит на 12 часов через Motorola 68000, чтобы затем определить длительности задержки. 28 мая 2007 года Motorola 68000 снова не делит из-за защиты от переполнения, которую Mac SCI игнорирует. [7]
В некоторых системах возникли проблемы после перехода на 2010 год. Некоторые СМИ окрестили это проблемой «Y2K+10» или «Y2.01k». [14]
Основным источником проблем была путаница между шестнадцатеричным кодированием чисел и кодированием чисел в формате BCD . Числа от 0 до 9 кодируются как в шестнадцатеричном, так и в формате BCD как 00 16 по 09 16 . Но десятичное число 10 кодируется в шестнадцатеричном как 0A 16 и в формате BCD как 10 16 . Таким образом, BCD 10 16 , интерпретированное как шестнадцатеричное кодирование, ошибочно представляет десятичное число 16.
Например, протокол SMS использует кодировку BCD для дат, поэтому некоторые программы для мобильных телефонов неправильно сообщали даты сообщений как 2016 год вместо 2010 года. Windows Mobile была первой программой, которая, как сообщалось, была затронута этим сбоем; в некоторых случаях WM6 изменяла дату любого входящего SMS-сообщения, отправленного после 1 января 2010 года, с 2010 года на 2016 год. [15] [16]
Другие затронутые системы включают терминалы EFTPOS [17] и PlayStation 3 (за исключением модели Slim). [18]
PlayStation 3 от Sony неправильно обработала 2010 год как високосный , поэтому несуществующее 29 февраля 2010 года было показано 1 марта 2010 года, что вызвало ошибку программы . [19]
Самый крупный сбой такого рода произошел в Германии, где более 20 миллионов банковских карт стали непригодными для использования, а также в Citibank Belgium, где перестали работать чипы идентификации клиентов Digipass. [20]
Тайвань официально использует календарь Минго , в котором григорианский год 1912 считается годом 1. Таким образом, григорианский год 2011 является годом 100 Китайской Республики, его первым годом из 3 цифр. [21] Это приводит к тому, что год отображается как 1911 (год 0), если используются двузначные представления.
Космический зонд Deep Impact потерял связь с Землей 11 августа 2013 года из-за проблемы с отметкой времени; дата хранилась как беззнаковое 32-битное целое число, подсчитывающее количество десятых долей секунды с 1 января 2000 года. [22]
В 2019 году произошел второй перенос номера недели GPS .
30 апреля 2019 года император Японии Акихито отрекся от престола в пользу своего сына Нарухито . Поскольку годы в Японии традиционно обозначаются названиями эпох , соответствующими правлению каждого императора, это привело к появлению нового названия эпохи, Рэйва (令和) , после восшествия Нарухито на престол на следующий день. Поскольку предыдущий император Хирохито умер 7 января 1989 года, а правление Акихито в основном совпало с ростом использования компьютеров, большая часть программного обеспечения не была протестирована на предмет корректного поведения при смене эпохи, в то время как тестирование было еще более осложнено тем фактом, что новое название эпохи не было раскрыто до 1 апреля 2019 года. Поэтому ожидались ошибки от программного обеспечения, которое не предвидело новую эпоху.
Видеоигры WWE 2K20 и Star Wars Jedi: Fallen Order вылетели 1 января 2020 года, когда год перешел на новый. Сбои можно было обойти, только сбросив год на 2019, пока не выйдет патч. [23] [ 24] Кроме того, Crystal Reports 8.5 не сможет генерировать определенные отчеты, начиная с 2020 года. [25]
Паркоматы Parkeon в Нью-Йорке и других местах не могли принимать кредитные карты в качестве формы оплаты с 2020 года. Был реализован обходной путь, но требовалось индивидуальное обновление каждого счетчика. В Нью-Йорке счетчики не должны были быть отремонтированы до 9 января. [26] [27]
В Польше 5000 кассовых аппаратов перестали правильно печатать дату. [28]
Умные спортивные часы Suunto отображали ошибку при вычислении дней недели, которые были представлены с шагом +2 (например, FRI вместо WED, SAT вместо THU). Для часов модели Suunto Spartan ошибка была исправлена в версии прошивки 2.8.32. [29]
Панель управления в Classic Mac OS версий 6, 7 и 8 позволяет устанавливать дату только до 31 декабря 2019 года, хотя система может продолжать переводить время и после этой даты. [30] [31]
Первая версия Microsoft Schedule+, поставляемая в комплекте с версией 3.0 почтового клиента Microsoft Mail, откажется работать с годами после 2020 года и позже, поскольку программа была разработана для работы в 100-летнем временном окне с 1920 по 2019 год. В результате дата может быть установлена только до 31 декабря 2019 года. [32]
Пользователи Samsung сообщили, что телефоны, работающие на последнем обновлении One UI 3.0 или Android 11, потеряли доступ к статистике аккумулятора и зарядки, начиная с 2021 года. Затронутые устройства не будут сообщать статистику использования, поэтому эти разделы останутся пустыми. [33] [34]
Даты, хранящиеся в формате ггммддЧЧММ, преобразованные в 32-разрядное целое число со знаком, переполнились 1 января 2022 года, так как 2 31 = 2147483648. Особенно пострадали номера обновлений компонента сканирования вредоносных программ Microsoft Exchange , которые, по-видимому, используются для математической проверки для определения последнего обновления. [35] [36]
Автомобили Honda и Acura , выпущенные в период с 2004 по 2012 год, оснащенные системами навигации GPS, неправильно отображали год 2002. Эта проблема была вызвана переполнением эпохи GPS. [37] [38] Проблема была решена 17 августа 2022 года. [39]
Считыватели платежных карт на бензоколонках в Новой Зеландии не смогли справиться с високосным годом и не смогли правильно выдавать бензин. [40]
Видеоигры EA Sports WRC и Theatrhythm Final Bar Line также столкнулись с проблемами, связанными с високосным годом: первая вылетала при попытке загрузить игру, а вторая утверждала, что данные сохранения были повреждены. Обе игры пришлось установить на следующий день 1 марта 2024 года, чтобы они работали должным образом. [41] [42] [43]
В Японии некоторые старые компьютерные системы, использующие японский календарь, которые не были обновлены, все еще считают годы по эре Сёва . 2025 год соответствует в этих системах Сёва 100, что может вызвать проблемы, если программное обеспечение предполагает две цифры для года. [44]
Некоторые системы хранят свой год как однобайтовое смещение от 1900, что дает диапазон 255 (8 бит) и позволяет безопасно представлять даты до 2155 года. Однако не все системы используют беззнаковый байт: некоторые были ошибочно закодированы с помощью знакового байта, который допускает только диапазон 127 лет, что означает, что поле даты в программном обеспечении будет неверным после 2027 года и может вызвать непредсказуемое поведение. Это влияет на несколько частей программного обеспечения оптических дисков, которые работают с использованием формата ISO 9660. [45]
В конце 1970-х годов в системах Data General Nova и Eclipse корпорация World Computer Corporation (выполняющая заявки кредитных союзов) создала формат даты с 16-битным полем даты для 128 лет (7 бит – обратите внимание, 1900+128=2028), 12 месяцев (4 бита) и 31 дня (5 бит). Это позволило напрямую сравнивать даты с помощью беззнаковых функций. Некоторые системы, включая HP 3000 , до сих пор используют этот формат, хотя внешние консультанты разработали патч. [46]
Palm OS использует как целые числа со знаком с эпохой 1970 года , так и целые числа без знака с эпохой 1904 года для различных системных функций, [47] таких как системные часы и даты файлов (см. формат PDB ). Хотя это должно привести к тому, что Palm OS будет подвержена проблеме 2038 года, Palm OS также использует 7-битное поле для хранения значения года с другим отсчетом эпох с 1904 года, что приводит к максимальному году 2031 (1904 + 127). [48]
В сетевом протоколе времени есть проблема переполнения, связанная с проблемой 2038 года , которая проявляется в 06:28:16 UTC 7 февраля 2036 года, а не в 2038 году. 64-битные временные метки, используемые NTP, состоят из 32-битной части для секунд и 32-битной части для дробной секунды, что дает NTP шкалу времени, которая переворачивается каждые 2,32 секунды (136 лет) и теоретическое разрешение 2−32 секунды (233 пикосекунды). NTP использует эпоху 1 января 1900 года. Первое переворачивание происходит в 2036 году, до проблемы 2038 года в UNIX. [49] [50]
Первоначальная реализация операционной системы Unix хранила системное время как 32-битное целое число со знаком, представляющее количество секунд после эпохи Unix (1 января 1970 г., 00:00:00 UTC). Это значение будет перенесено после 19 января 2038 г., 03:14:07 UTC. Эта проблема была решена в большинстве современных операционных систем Unix и Unix-подобных операционных систем путем хранения системного времени как 64-битного целого числа со знаком, хотя отдельные приложения, протоколы и форматы файлов также должны быть изменены.
Подобно проблеме с переводом времени в Unix, 32-разрядная версия gmtime в библиотеках времени выполнения C в Windows имеет похожую проблему. [51]
Эта проблема уже проявилась в Oracle Access Manager версии 10.1.4.3 для Windows. Компонент Identity Console устанавливает файл cookie, содержащий настройки пользовательского интерфейса , со сроком действия 500 000 000 секунд в будущем (около 16 лет). Это происходит после 19 января 2038 года, поэтому он выдает исключение для определенных поисковых действий после 02:20:48 UTC 17 марта 2022 года, поскольку вызов gmtime_r() не может преобразовать предоставленное число в дату для записи в файл cookie. [52] Несмотря на возраст программного обеспечения (18 июня 2009 года), Oracle выпустила исправление под номером 33983548 6 апреля 2022 года.
Третий переход на новую GPS-неделю произойдет 20 ноября 2038 года в 23:59:37 UTC.
Ранние компьютеры Apple Macintosh хранят время в своих часах реального времени (RTC) и файловых системах HFS как беззнаковое 32-битное число секунд с 00:00:00 1 января 1904 года. После 06:28:15 6 февраля 2040 года (т. е. 2 32 −1 секунды от начала эпохи) это время вернется к 1904 году: [53] кроме того, HFS+ , формат по умолчанию для всех последних компьютеров Apple Macintosh, также затронут. Заменяющая файловая система Apple решает эту проблему.
ProDOS для компьютеров Apple II поддерживает только двузначные номера года. Чтобы избежать проблем Y2K, Apple выпустила техническую записку, в которой говорилось, что номер года должен представлять 1940–2039. [54] Программное обеспечение для платформы может неправильно отображать даты, начинающиеся с 2040 года, хотя сторонние компании прилагают усилия по обновлению ProDOS и прикладного программного обеспечения для поддержки лет до 4095. [55]
18 сентября 2042 года часы времени суток (TODC) на мэйнфрейме IBM S/370 и его преемниках, включая текущую zSeries, будут переведены. [56]
Более старые TODC были реализованы как 64-битный счетчик единиц 2 −12 микросекунд (0,244 нс), а стандартной базой было 1 января 1900 года, UT . В июле 1999 года были анонсированы расширенные часы TODC, которые расширили часы вправо (то есть расширенные биты менее значимы, чем исходные биты). Фактическое разрешение зависит от модели, но формат является согласованным и, следовательно, будет переходить через 2 52 микросекунды. [56]
Значение TODC доступно программам пользовательского режима и часто используется для хронометража и генерации уникальных идентификаторов событий.
Хотя IBM определила и реализовала более длинный (128-битный) аппаратный формат на последних машинах, который расширяет таймер с обеих сторон как минимум на 8 дополнительных бит, многие программы продолжают полагаться на 64-битный формат, который остается доступным подмножеством более длинного таймера.
Логика планирования мощностей в системе ERP SAP S/4HANA поддерживает только даты окончания до 19 января 2048 года (24 855 дней с 1 января 1980 года, что соответствует 2 31 секунде, округленной до полных дней). Это касается, например, планирования производства, технического обслуживания и инспекций. [57]
Согласно Единой спецификации UNIX для анализа двузначных годов с использованием strptime(), «значения в диапазоне [69,99] должны относиться к годам с 1969 по 1999 включительно, а значения в диапазоне [00,68] должны относиться к годам с 2000 по 2068 включительно» [58] , что означает, что при анализе с помощью strptime(), двузначный год «69» будет интерпретироваться как 1969, а не как 2069.
Программы, которые хранят даты как количество дней с произвольной даты (или эпохи ), уязвимы к эффектам переполнения или переноса, если значения недостаточно широки, чтобы позволить значениям даты охватывать достаточно большой временной диапазон, ожидаемый для приложения. Знаковые 16-битные двоичные значения переходят через 32 768 (2 15 ) дней с даты эпохи, производя отрицательные значения. Некоторые мэйнфреймовые системы испытывали программные сбои, поскольку они кодировали даты как количество дней с 1 января 1900 года, что производило неожиданные отрицательные числа дней на дату перетекания 18 сентября 1989 года. Аналогично, беззнаковые 16-битные двоичные числа дней переполняются через 65 536 (2 16 ) дней, которые усекаются до нулевых значений. Для программного обеспечения, использующего эпоху 1 января 1900 года, это произойдет 6 июня 2079 года. [59]
Некоторые (если не все) телефоны Nokia, работающие на Series 40 (например, Nokia X2-00 ), поддерживают только даты до 31 декабря 2079 года и, таким образом, не смогут отображать даты после этой даты. Одним из обходных путей является использование года 1996, 2024 или 2052 вместо 2080 (как совместимые високосные годы) для отображения правильного дня недели, даты и месяца на главном экране. [ необходима цитата ]
Системы, хранящие год только в виде двузначного значения 00..99, как и многие часы реального времени, могут перейти с 31 декабря 2079 года на эпоху IBM PC и DOS 1980-01-01 .
API и функции преобразования даты файлов DOS и Windows (например, INT 21h /AH=2Ah) официально поддерживают даты только до 31 декабря 2099 года (хотя базовая файловая система FAT теоретически поддерживает даты до 2107 года). Следовательно, операционные системы на базе DOS, а также приложения, преобразующие другие форматы в формат FAT/DOS, могут демонстрировать неожиданное поведение, начиная с 1 января 2100 года.
Аналогично, Nintendo DS и GameCube, а также Sony PlayStation 4 позволяют пользователям устанавливать даты только до 2099 года. В случае с Nintendo DS система не будет переводить время дальше 31 декабря 2099 года, тогда как GameCube и PS4 по-прежнему будут переводить его на 2100 год и далее, хотя пользователи этих игровых консолей не могут вручную вводить дату и время до такого отдаленного периода.
Другая проблема возникнет в конце 28 февраля 2100 года, поскольку 2100 год не является високосным . Поскольку многие распространенные реализации алгоритма високосного года неполны или упрощены, они могут ошибочно предположить, что 2100 год является високосным, в результате чего дата перейдет с 28 февраля 2100 года на 29 февраля 2100 года вместо 1 марта 2100 года.
Многие существующие форматы файлов, протоколы связи и интерфейсы приложений используют вариант формата даты Unix time_t , сохраняя количество секунд с начала эпохи Unix (полночь UTC, 1 января 1970 года) в виде беззнакового 32-битного двоичного целого числа. Это значение перейдет 7 февраля 2106 года в 06:28:15 UTC. То есть в настоящее время количество секунд с 1 января 1970 года составляет FFFF FFFF в шестнадцатеричном формате.
Эта проблема представления хранилища не зависит от программ, которые внутри себя хранят и обрабатывают системное время как 64-битные целочисленные значения со знаком.
Метки даты и времени, хранящиеся в файловых системах FAT , первоначально представленные в 86-DOS 0.42 в 1981 году и перенесенные в MS-DOS , PC DOS , DR-DOS и т. д., переполнятся в конце 31 декабря 2107 года. Метка даты последнего изменения (а с DELWATCH 2.0+ также метка даты удаления файла , а с DOS 7.0+ опционально также метка даты последнего доступа и метка даты создания ) хранятся в записи каталога с годом, представленным в виде беззнакового семибитного числа (0–127) относительно 1980 года, и, таким образом, не могут указывать на какие-либо даты в 2108 году и позже. Функции API , определенные для извлечения этих дат, официально поддерживают только даты до 31 декабря 2099 года.
Это также повлияет на формат файла архива ZIP , поскольку он использует внутренние метки времени модификации файлов FAT.
Даты GPS выражаются как номер недели и номер дня недели, причем номер недели изначально использует десятибитное значение , а модернизированные навигационные сообщения GPS используют 13-битное поле. Десятибитные системы будут обновляться каждые 1024 недели (около 19,6 лет) после воскресенья 6 января 1980 года ( эпоха GPS ), а 13-битные системы обновляются каждые 8192 недели. Тринадцатибитные системы будут обновляться до нуля в 2137 году. [10] [11]
RISC OS хранит даты в виде сотых секунд с 1 января 1900 года в пяти байтах – 40 бит. Эти временные метки используются внутри и отображаются в метаданных файла (адреса загрузки и выполнения). [60] Эта эпоха заканчивается 3 июня 2248 года в 06:57:57.75 UTC.
Некоторые системы хронометража считают наносекунды с 1970 года, используя 64-битное целое число со знаком, которое переполнится 11 апреля 2262 года, 23:47:16. API языка программирования Go UnixNano является одним из примеров. [61] Другие примеры включают объект Timestamp в Python pandas , [62] C++ chrono::nanoseconds, [63] и таймеры QEMU . [64]
Системы, использующие строку длиной 10 символов для записи времени Unix, могут испытывать проблемы с сообщением времени после 20 ноября 2286 года, 17:46:39, через десять миллиардов секунд после эпохи Unix.
В ext4 , файловой системе по умолчанию для многих дистрибутивов Linux, нижние два бита {a,c,m}time_extraиспользуются для расширения {a,c,m}timeполей, откладывая проблему 2038 года до 2446 года. [65]
В этом «дополнительном» 32-битном поле нижние два бита используются для расширения 32-битного поля секунд до ширины 34 бита; верхние 30 бит используются для обеспечения точности временной метки в наносекундах. Поэтому временные метки не должны переполняться до мая 2446 года. [66]
В масштабах времени в тысячи лет григорианский календарь отстает от астрономических сезонов. Это происходит потому, что скорость вращения Земли постепенно замедляется , что делает каждый день немного длиннее с течением времени (см. приливное ускорение и високосную секунду ), в то время как год сохраняет более равномерную продолжительность.
В 19 веке сэр Джон Гершель предложил модификацию григорианского календаря с 969 високосными днями каждые 4000 лет, вместо 970 високосных дней, которые григорианский календарь вставлял бы за тот же период. [67] Это сократило бы средний год до 365,24225 дней. Предложение Гершеля сделало бы год 4000 и кратные ему годы обычными, а не високосными. Хотя эта модификация часто предлагалась с тех пор, она никогда не была официально принята. [68]
В то время как большинство программ (включая Excel , JavaScript и R ) в настоящее время распознают 4000 и 8000 как високосные годы (так как они делятся на 400), SAS приняла «правило 4000 лет». Таким образом, с текущим программным обеспечением преобразования дат между SAS и другим программным обеспечением выйдут из синхронизации после 28 февраля 4000 года. [69] [70]
Microsoft Outlook использует дату 1 января 4501 года в качестве заполнителя для «нет» или «пусто». [71] [72]
Год 10 000 станет первым григорианским годом с пятью цифрами. Все будущие годы, которые являются степенями 10, а также даты до 10-го тысячелетия до н. э. , сталкиваются с аналогичными проблемами кодирования.
Эту проблему можно увидеть в программе электронных таблиц Microsoft Excel по состоянию на 2023 год, которая хранит даты как количество дней с 31 декабря 1899 года (день 1 — это 1 января 1900 года) с вымышленным високосным днем в 1900 году , если используется система дат по умолчанию 1900 года. В качестве альтернативы, если используется система дат 1904 года, дата хранится как количество дней с 1 января 1904 года (день 1 — это 2 января 1904 года), и проблемы високосного года не возникает. Максимальная поддерживаемая дата для расчета — 31 декабря 9999 года. [73] [74]
В операционных системах Microsoft WindowsFILETIME структура хранит число 100-наносекундных интервалов, известных как «тики», начиная с 00:00:00.0000000 UTC 1 января 1601 года в виде 64-битного целого числа со знаком. DateTimeСтруктура в языке программирования C# также хранит 100-наносекундные тики с 00:00:00 UTC, но начинается с 1 января 1 г. н. э. по пролептическому григорианскому календарю . [75] Эти значения превысят максимально возможное значение в 30 828 и 29 228 годах, [76] [77] соответственно, 14 сентября в 02:48:05.4775808 UTC, после чего Windows не будет принимать даты после этого дня и будет отображать ошибки «недопустимое системное время» в NTFS. [78]
Программы, обрабатывающие годы как 16-битные значения, могут столкнуться с проблемами при работе с годом 32 768 или 65 536, в зависимости от того, рассматривается ли значение как целое число со знаком или без знака.
Для задачи 32 768 года годы после 32 767 могут быть интерпретированы как отрицательные числа, начиная с −32 768. [79] Задача 65 536 года , скорее всего, проявится, если представить год 65 536 как год 0. [80]
Архивы статических библиотек, созданные командой ar Unix, хранят временные метки в виде строки ASCII, содержащей десятичное число секунд после эпохи Unix (1 января 1970 г., 00:00:00 UTC), с ограничением в 12 символов ASCII. Это значение будет обновлено после 01:46:39 27 сентября 33658 г. [ необходима цитата ]
100 000 год станет первым годом по григорианскому календарю с шестью цифрами.
API дат JavaScript хранит даты в виде количества миллисекунд с 1 января 1970 года. Даты имеют диапазон ±100 000 000 дней от эпохи, что означает, что программы, написанные на JavaScript с использованием API дат, не могут хранить даты после 13 сентября 275 760 года нашей эры. [81]
Задача 292,277,026,596 года ( приблизительно2,92 × 10 11 лет в будущем) произойдет, когда 64-битное время Unix переполнится после 15:30:08 UTC в воскресенье, 4 декабря 292 277 026 596 года нашей эры. [82] [83] Этот год находится настолько далеко в будущем (намного дальше вероятной продолжительности жизни Земли , Солнца , человечества и даже за пределами некоторых предсказаний продолжительности жизни Вселенной ), что на него в основном ссылаются как на предмет теоретического интереса, шутки или указания на то, что более ранние версии, такие как проблема 2038 года, не могут быть по-настоящему «решены» навсегда.
В Microsoft Windows 7, Windows Server 2003, Windows Server 2008 и Windows Vista информация о начале TCP-подключения хранилась в сотых долях секунды с использованием 32-битного беззнакового целого числа, что приводило к переполнению и сбою TCP-подключений через 497 дней. [84]
В Microsoft Windows 95 и Windows 98 возникала проблема с 2-32 - миллисекундным сбрасыванием в драйвере виртуального устройства (VTDAPI.VXD), что приводило к зависанию системы через 49,7 дней. [85]
В .NET до версии 6.0 была ошибка, из-за которой восхождение на вершину пула потоков периодически прекращалось через 49,7 дней из-за переполнения при обработке миллисекунд с момента запуска. [86]
У самолета Boeing 787 было по крайней мере две проблемы с программным обеспечением, связанные с хранением времени. В 2015 году была зарегистрирована ошибка, при которой время хранилось в сотых долях секунды с использованием 32-битного целого числа со знаком, и система выходила из строя через 248 дней. [87]
В 2020 году FAA выпустило директиву по летной годности для решения проблемы, при которой, если самолет не будет полностью выключен до достижения 51 дня безотказной работы, системы начнут отображать вводящие в заблуждение данные. [88]
Платформа Arduino предоставляет относительное время через функцию millis(). Эта функция возвращает беззнаковое 32-битное значение для «миллисекунд с момента запуска», которое предназначено для обновления каждые 49,71 дня. По умолчанию это единственный источник синхронизации, доступный на платформе, и программы должны проявлять особую осторожность при обработке обновлений. [89] Внутри millis() основан на подсчете прерываний таймера. Определенные режимы энергосбережения отключают прерывания и, следовательно, останавливают движение счетчика во время сна. [90]
Также для исторических лет могут возникнуть проблемы с обработкой исторических событий, например:
{{cite mailing list}}: Отсутствует или пусто |url=( помощь ) Воспроизведено в: Austein, Rob (30 января 1987 г.). Neumann, Peter G. (ред.). "DATE-86, или Призрак прошлого Tinkles". The RISKS Digest . 4 (45). Форум по рискам для общественности в компьютерах и связанных с ними системах, Комитет ACM по компьютерам и государственной политике (опубликовано 2 февраля 1987 г.) . Получено 29 декабря 2014 г.OS/8 может хранить даты только за 8-летний период...
COS-310, коммерческая операционная система DEC для PDP-8 ... файловая система почти такая же, как OS/8, но даты записываются по-другому