Ошибки форматирования и хранения времени

Ограничения типа данных и программные ошибки могут вызвать ошибки в вычислениях времени и даты или при их отображении. Чаще всего это проявляется как целочисленное переполнение, но может быть результатом и других проблем. Наиболее известным примером такого типа является проблема 2000 года, но существует множество других значимых дат и времён, которые вызывали или будут вызывать проблемы из-за различных недостатков в программировании.

5 января 1975 года 12-битное поле, использовавшееся тогда для дат в операционной системе TOPS-10 для компьютеров DEC PDP-10, переполнилось, и этот баг получил название «DATE75». Значение поля вычислялось как число лет, прошедших с 1 января 1964 года, умноженное на 12, затем добавлялось число месяцев, прошедших с января, умножалось на 31, и, наконец, добавлялось число дней с начала месяца. Максимальное значение, которое может быть представлено беззнаковым 12-битным целым равно 2¹² − 1 = 4095, и значение 4095 соответствует 4 января 1975 года: ${\displaystyle (((11{\text{ лет с 1964 года}})\times 12)+0{\text{ месяцев с начала года}})\times 31)+3{\text{ дней с начала месяца}}=4095}$

Поэтому 4 января 1975 является последней датой, которую можно закодировать. Заплата "DATE-75" сдвинула дату, которую можно закодировать, на 1 февраля 2052 года, установив дату переполнения 2 февраля 2052, за счёт использования 3 свободных битов других полей в метаданных файловой системы, но это иногда вызывало проблемы с программным обеспечением, которое использовало эти поля для своих собственных целей. Некоторое программное обеспечение, возможно, поддерживало использование одного дополнительного бита для даты, но имело проблемы с дополнительными битами, что могло привести к некоторым ошибкам 9 января 1986 года^{[1][2][3][4][5]}.

Операционная система OS/8 компании Digital Equipment Corporation для компьютера PDP-8 использовала знаковый четырёхбитный полубайт для хранения числа годов с 1970 года, а это могло представить только года с 1970 по 1977^[5][6].

Это было обнаружено при разработке операционной системы COS-310 и даты записывались другим образом^[7].

Многие игры Sierra Entertainment, выпущенные для классической Mac OS, начали зависать 18 сентября 1993. Проблема заключалась в версии интерпретатора (Mac SCI), которая «блокировала» игру при попытке обработать задержку, что было вызвано переполнением. Mac SCI пытался использовать дату для определения продолжительности задержки, получая текущее время в секундах с 1 января 1904 года (эпоха Macintosh (см. Год 2040), и делил полученное время на 12 часов. Деление проводилось на процессоре Motorola 68000 и не осуществлялось, если в результате деления обнаруживалось переполнение, но Mac SCI продолжал работать, как будто деление было выполнено, что приводило к задержке вместо одной секунды к задержке в 18 часов. Sierra выпустила исправление с названием MCDATE, которое решило проблему почти на 14 лет (см. Год 2007)^[8][9].

В операционной системе Domain/OS компании Apollo Computer абсолютное время хранилось как знаковое 48-битное целое, соответствующее числу 4-микросекундных интервалов с 1 января 1980 года. Это значение переполнилось 2 ноября 1997 года, сделав необновлённые системы неработоспособными^[5][10].

За последние несколько месяцев до наступления 2000-го года случилось две проблемы, связанные с датами, но получившими меньше освещения, чем тогдашняя надвигающаяся проблема Y2K.

Даты в системе GPS представлены номером недели и номером дня недели, при этом номер недели передаётся как десятибитное значение. Это означает, что каждые 1024 недели (около 19,6 лет) после воскресенья 6 января 1980 года (GPS эпоха, дата сбрасывается. Это произошло первый раз в 23:59:47 21 августа 1999 года^[11][12], второй раз в 23:59:42 UTC 6 апреля 2019 года и следующий раз произойдёт 20 ноября 2038 года^[13]. Чтобы решить эту проблему, в модернизированных навигационных сообщениях GPS используется 13-битное поле, которое повторяется только каждые 8192 недели (157 лет) и не вернётся к нулю до 2137 года^[5][14].

Многие устаревшие программы или наборы данных использовали дату «9.9.99» как признак конца для обозначения неприсвоенной даты или как конец набора данных, чтобы показать, что дальше данных нет. Это приводило к сбоям многих систем при наступлении реальной даты, которую она представляла: 9 сентября 1999 года^[5][11].

Термин «проблема 2000-го года», или просто Y2K, относится к потенциальным ошибкам, связанным с форматированием и хранением календарной даты для 2000-го года и далее. Многие программы представляли четырёхзначные года только последними двумя знаками, что делает год 2000 неотличимым от 1900-го года. Неспособность компьютерных систем правильно распознавать даты могла привести к коллапсу глобальной инфраструктуры в отраслях, зависящих от компьютеров.

Для приложений, которым необходимо рассчитывать год рождения (или другой год в прошлом), такой алгоритм давно использовался для решения проблемы 1900-го года, но он не может распознать людей старше 100 лет.

Системы, использующие строку длиной девять символов для записи времени в секундах с начала эпохи Unix имели проблемы с отображением времени, выходящего за пределы одного миллиарда секунд после начала эпохи 9 сентября 2001 года в 01:46:40. Проблемы не были широко распространены^[5][15].

Игры от 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 игнорирует факт, что фактического деления не было^[8].

Некоторые системы имели проблемы, когда год сменился на 2010. В СМИ это явление упоминалось как проблема «Y2K+10» или «Y2.01k»^[16].

Главной причиной проблемы было смешение шестнадцатеричной и двоично-десятичной систем кодирования чисел. Числа от 0 до 9 в обоих системах кодировались от 00₁₆ до 09₁₆. Однако десятичное число 10 кодировалось в шестнадцатеричном коде как 0A₁₆, а в двоично-десятичном коде как 10₁₆. Таким образом, двоично-десятичное число 10₁₆ ошибочно интерпретировалось как шестнадцатеричное, что соответствует десятичному числу 16.

Например, SMS протокол использует двоично-десятичное кодирование дат, так что некоторые программы на телефонах ошибочно в сообщениях указывали 2016-й год вместо 2010-го. Windows Mobile было первым программным обеспечением, пострадавшим от этой ошибки. В некоторых случаях WM6 меняла год любого входящего SMS сообщения, посланного после 1 января 2010 года, с 2010 на 2016^[5][17][18].

Наиболее заметный сбой произошел в Германии, где более 20 миллионов банковских карт стали непригодными для использования, а также в Citibank Belgium, чьи идентификационные чипы клиентов перестали работать^[19].

К другим затронутым системам относятся терминалы EFTPOS^[20], и PlayStation 3 (кроме модели Slim)^[21]. PlayStation 3 от Sony ошибочно считала 2010 год високосным, поэтому несуществующая дата 29 февраля 2010 года отображалась 1 марта 2010 года, что приводило к ошибке программы^[5][22].

Тайвань официально использует календарь Миньго, по которому грегорианский 1912 год считается первым годом. Поэтому 2011 год по грегорианскому календарю будет 100-м годом по календарю Миньго, а это первый 3-значный год^[5][23]. Таким образом, год будет показываться как 1911-й год (нулевой год), если используется двухзначное представление.

Космический зонд Deep Impact потерял связь с Землёй 11 августа 2013 года, из-за проблемы с метками времени. Дата хранилась как беззнаковый 32-битный целочисленный счётчик десятых долей секунды с 1 января 2000 года^[24].

В 2019 году произошло второе GPS переполнение числа недель^[25]. Компьютеризированные телескопы Meade с GPS, такие как LX200GPS, не могли больше определять своё местоположение, а потому не могли самостоятельно наводиться или находить звёздные объекты. Компания Meade выпустила прошивку версии 4.2k с исправлением, но она также внесла несколько новых ошибок. Версия 4.2l (буква L в нижнем регистре, не спутайте с заглавной I) была выпущена для исправления внесённых ошибок, но и эта версия содержала ещё больше необъяснимых изменений. Сторонняя разработка, StarPatch, бесплатно выпустила взломанную версию прошивки 4.2g для решения этих проблем.

30 апреля 2019 года японский император Акихито отрёкся от престола в пользу своего старшего сына Нарухито. Поскольку годы в Японии традиционно обозначаются названиями эпох, соответствующих правлению каждого императора, это привело к появлению нового названия эпохи — Рэйва (яп. 令和) — после восшествия Нарухито на престол на следующий день. Поскольку предыдущий император, Хирохито, скончался 7 января 1989 года, а правление Акихито в основном совпало с ростом использования компьютеров, большинство программ не было протестировано на корректное поведение при смене эпохи. Тестирование было дополнительно осложнено тем, что новое название эпохи было объявлено только 1 апреля 2019 года. Следовательно, ожидались ошибки в программах, которые не предусматривали новую эпоху.

Видеоигры WWE 2K20 и Star Wars Jedi: Fallen Order дали сбой 1 января 2020 года при переходе на следующий год. Обойти эти ошибки до выхода исправления можно было только сбросив год на 2019^[26][27]. Crystal Reports 8.5 перестали генерировать определенные отчеты начиная с 2020 года^[28].

Парковочные автоматы Parkeon в Нью-Йорке и других местах с 2020 года не могли принимать кредитные карты в качестве оплаты. Было найдено временное решение, но оно требовало индивидуального обновления каждого автомата. В Нью-Йорке ожидалось, что проблема с автоматами будет устранена только 9 января^[29][30].

В Польше 5000 контрольно-кассовых машин перестали корректно печатать даты^[31].

Спортивные смарт-часы Suunto показывали ошибку в вычислении дней недели, показывая дни, которые опережали фактические на два дня (например, FRI (пятница) вместо WED (среда), SAT (суббота) вместо THU (четверг)). Для модели Suunto Spartan ошибка была исправлена с выпуском прошивки версии 2.8.32^[32].

Панель управления в версиях Classic Mac OS 6, 7 и 8 позволяет установить дату только до 31 декабря 2019 года , хотя система способна продолжать отсчёт времени после этой даты^[5][33][34].

Программа Microsoft Schedule+ версия 1.0 (поставлялась с почтовым клиентом 3.0 Microsoft Mail) отказывается работать с годами, большими 2020 года, поскольку программа была разработана для работы в пределах столетнего окна времени с 1920-го по 2019-й год. В результате, максимальная дата, которую можно установить — 31 декабря 2019 года. Microsoft заявляет, что это было сделано намеренно^[35].

Пользователи телефонов Samsung сообщали, что телефоны с системами One UI 3.0 update или Android 11 с 2021 года теряли доступ к статистике батареи и зарядки. Затронутые устройства не отображали статистику использования, оставляя эти разделы пустыми^[36][37].

В протоколе GPSD была обнаружена серьезная ошибка, которая могла бы привести к непредсказуемым последствиям. Речь идет о самопроизвольном переключении времени на март 2002 года, то есть время бы сдвинулось на 19 лет назад. Ошибка должна была проявиться 24 октября 2021 года. Это бы привело к очень серьезным проблемам в работе систем, которые задействуют службу GPSD. В частности, пользователи могли бы столкнуться с проблемами аутентификации, сбоями в механизмах проверки доступа и др.

К счастью, ошибка была своевременно обнаружена и устранена в выпуске GPSD 3.23. Пользователям, которые используют данный протокол в работе оборудования, было предложено срочно установить обновление и тем самым предотвратить сбой^[38].

Даты, сохранённые в формате yymmddHHMM при преобразовании в 32-битное целое со знаком вызывали переполнение 1 января 2022, поскольку 2³¹ = 2147483648. Особо затронуты были обновления компонента сканирования на вирусы в Microsoft Exchange, которые, по-видимому, использовались для математической проверки определения последней версии обновления^[39][40].

Автомобили Honda и Acura, выпущенные между 2004 и 2012 годами и оснащённые системами GPS навигации неверно показывали год как 2002. Проблема была вызвана переполнением времени GPS эпохи^[41][42]. Проблема была решена 17 августа 2022 года^[43].

Платёжные терминалы на бензоколонках в Новой Зеландии не смогли корректно обработать високосный год и не могли заправлять автомобили бензином^[44].

Видеоигры EA Sports WRC и Theatrhythm Final Bar Line также столкнулись с проблемой високосного года. Первая игра вылетала при попытке загрузки игры, а вторая сообщала, что сохранённая игра повреждена. Для нормальной работы обоих игр требовалось установить дату на следующий день после 1 марта 2024 года^[45][46][47].

В декабре 2024 был найден 30-летний баг во всех версиях HCL Notes. При запуске сервера 13 декабря 2024 года или позднее переполнение данных препятствовало загрузке конфигурации почтового маршрутизатора, так что никакая почта не поступала. На следующий день были выпущены исправления для всех поддерживаемых версий^[48].

В Японии некоторые старые компьютерные системы, использующие японский календарь и не прошедшие обновление, до сих пор отсчитывают годы по эпохе Сёва. В этих системах год 2025 соответствует году Сёва 100, что может вызвать проблемы, если программное обеспечение использовало две цифры для года^[49].

В Испании все поезда класса Talgo AVRIL остановили работу 1 января 2025 года вследствие бага обработки даты в модуле зарядки аккумуляторов, что вызвало задержки и отмены, поскольку пассажиров пересаживали на другой подвижной состав^[50][51]. Исправление было внесено на следующий день и сервис был восстановлен^[52].

Баг в команде date из uutils, переписанной на Rust версии GNU Core Utilities, привёл к тому, что автоматическое обновление Ubuntu 25.10 перестало работать^[53][54].

Системное время консоли Xbox 360 может быть установлено только до 23:59 31 декабря 2025 года. Система продолжит отсчёт времени после этого, но пользователь уже не может установить дату после этой точки.

Некоторые устаревшие системы хранят год как однобайтовое смещение от 1900-го года, что даёт диапазон в 255 лет (8 бит) и позволяет успешно представить даты вплоть до 2155 года. Однако, не все системы используют беззнаковый байт — некоторые ошибочно закодированы со знаковым байтом, что сужает диапазон до 127 лет, тем самым делая поле даты в программах неправильным после 2027 года и может привести к непредсказуемым последствиям. Некоторое программное обеспечение для оптических дисков, использующее формат ISO 9660, подвержено этой ошибке^[55].

В конце 1970-х годов компания World Computer Corporation, занимавшаяся разработкой программного обеспечения для кредитных союзов, создала формат даты для систем Data General Nova and Eclipse. Формат использовал 16-битное поле даты, использовавшее семь бит для года, четыре бита для месяца и пять бит для дня. Это позволяло напрямую сравнивать даны с помощью беззнаковых функций. Некоторые системы, вклюяая HP 3000, продолжают использовать этот формат, хотя сторонние консультанты разработали для него исправление^[56].

Palm OS использует как целые со знаком с начала эпохи 1970 года, так и беззнаковые целые эпохи 1904 года, для различных системных функций^[57], таких как системные часы и файловые даты (см. PDB format). Хотя это должно привести к проблеме 2038 года, Palm OS использует также 7-битное поле для хранения значения года с другой эпохой, отсчитываемой от 1904 года, что дает максимальный год 2031, то есть через 127 лет после 1904 года^[58].

Протокол сетевого времени (англ. Network Time Protocol, NTP) имеет проблему переполнения, связанную с проблемой 2038 года, но проявляется в 06:28:16 UTC 7 февраля 2036 года, а не в 2038 году. 64-битное представление времени, используемое NTP, состоит из 32-битной части для секунд и 32-битной части для долей секунды, что даёт NTP временну́ю шкалу, которая переполняется каждые 2³² секунд (136 лет) и имеет теоретическое разрешение в 2⁻³² секунды (233 пикосекунды). NTP использует эпоху 1 января 1900 года. Первое переполнение произойдёт в 2036, до проблемы UNIX 2038 года^[5][59][60].

В первоначальной реализации операционная система Unix хранила системное время 32-битное знаковое целое как число секунд с начала эпохи (1 января 1970 00:00:00 UTC). Это значение переполнится 19 января 2038 года в 03:14:07 UTC, что соответствует 2³¹ − 1 = 2.147.483.647 секунд с начала эпохи. Эта проблема была решена в большинстве современных Unix и Unix-подобных операционных системах путём использования 64-битных знаковых целых чисел, хотя также необходимо изменить отдельные приложения, протоколы и форматы файлов.

Подобно проблеме с переполнением времени Unix, 32-битная версия функция gmtime в C библиотеках времени выполнения для Windows имеет схожую проблему^[61].

Эта проблема уже проявилась в версии 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^[62]. Несмотря на возраст программного обеспечения (18 июня 2009 года), Oracle выпустила исправление под номером 33983548 6 апреля 2022 года.

Третье GPS переполнение числа недель произойдёт 20 ноября 2038 года в 23:59:37 UTC.

Следующее обнуление 2038 года может и не состояться, так как GPS планируется перевести на тринадцатибитное представление недель. 2 в тринадцатой степени – это 8192. Следовательно, нужно будет подождать около 157 лет^[63].

Компьютеры Apple Mac до версии Mac OS X Snow Leopard хранили время в часах реального времени (англ. real-time clock, RTC) и файловой системой HFS (иерархическая файловая система, англ. Hierarchical File System) как беззнаковое 32-битное число секунд с 00:00:00 1 января 1904 года. После 06:28:15 6 февраля 2040 года, (то есть 2³² − 1 секунд с начала эпохи), произойдёт переполнение и дата вернётся к 1904 году^[5][64]. Кроме того, это также влияет на HFS+, являвшуюся ранее файловой системой по умолчанию для большинства компьютеров Apple. Apple File System, которая пришла на смену HFS и HFS+, решает эту проблему.

ProDOS, использовавшаяся на компьютерах Apple II, поддерживает только двузначные номера годов. Чтобы избежать проблем Y2K, выпустила техническую заметку, в которой указывалось, что номер года должен представлять период с 1940 по 2039 год^[65]. Программное обеспечение для этой платформы может некорректно отображать даты, начиная с 2040 года, хотя сторонние разработчики работают над обновлением ProDOS и прикладного программного обеспечения для поддержки годов до 4095^[66].

18 сентября 2042 года произойдёт переполнение счётчика времени (англ. Time of Day Clock, TODC) на компьютерах IBM System/370 линии мейнфреймов IBM и их последующих моделях, включая современную серию IBM Z^[5][67].

Ранние версии TODC были реализованы как 64-битные счётчики 2⁻¹² микросекунд (0,244 наносекунд) и базовой точкой отсчёта была 1 января 1900 года UT. В июле 1999 года было объявлено о расширенной версии TODC, в которой были добавлены разряды справа (то есть, добавленные биты менее значимы). Фактическое разрешение зависит от модели, но формат остается неизменным, и поэтому переполнение произойдет через 2⁵² микросекунды^[67].

Значение TODC доступно программам пользовательского режима и часто используется для синхронизации и генерации уникальных ID событий.

Хотя IBM определила и реализовала более длинный (128-битный) аппаратный формат на последних машинах, который расширяет таймер с обеих сторон как минимум на 8 дополнительных бит, многие программы продолжают полагаться на 64-битный формат, который остаётся доступным подмножеством более длинного таймера.

Планирование технического обслуживания в системе ERP SAP S/4HANA поддерживает даты завершения только до 19 января 2048 года (24855 дней с 1 января 1980 года, что соответствует 2³¹ секунд, округлённых до полных дней). Это касается инструментов планирования производства, технического обслуживания и инспекций^[68]. Эта проблема была устранена в более поздних обновлениях и теперь система поддерживает даты до 9999 года.

Переполнение числа недель в GPS произойдёт в четвёртый раз в 23:59:41 7 июля 2058 года.

Согласно Единой спецификации UNIX для разбора двухзначных годов с помощью strptime(), «значения в диапазоне [69, 99] относятся к годам с 1969 по 1999 включительно, а значения в диапазоне [00, 68] относятся к годам с 2000 по 2068 включительно»^[5][69]. Это означает, что при разборе функцией strptime() двухзначный год «69» будет интерпретирован как 1969, а не 2069.

Программы, хранящие даты в виде дней с определённой произвольной даты (или эпохи) подвержены проблемам переполнения или возврату к началу, если выделенные диапазоны значений недостаточно велики, чтобы охватить ожидаемый для приложения временной диапазон. 16-битные знаковые двоичные числа переполняются через 32768 (2¹⁵) дней с начала эпохи, становясь отрицательными. Некоторые мейнфреймы столкнулись с программными сбоями из-за того, что даты кодировались как количество дней с 1 января 1900 года, что привело к неожиданному появлению отрицательных значений дней при переходе 18 сентября 1989 года. Аналогично, беззнаковые 16-битные двоичные счётчики дней переполняются после 65536 (2¹⁶) дней, после чего значения обнуляются. Для программ, использующих в качестве эпохи 1 января 1900 года, это произойдет 6 июня 2079 года^[5].

Некоторые (если не все) телефоны Nokia на платформе Series 40 (такие как Nokia X2-00) поддерживают даты только до 31 декабря 2079 года и неспособны отображать даты после этого срока. Одним из обходных путей является использование 1996, 2024 или 2052 года вместо 2080-го (как совместимых високосных лет) для отображения правильного дня недели, даты и месяца на главном экране.

Многие системы IBM PC и DOS хранят год в виде двухзначного значения от 1980 года, как и многие RTC (часы реального времени), что приведёт к переполнению после 31 декабря 2079 года.

Функции API для работы с датами в DOS и Windows (например, INT 21h/AH=2Ah) официально поддерживают даты до 31 декабря 2099 года (хотя сама файловая система FAT теоретически поддерживает даты до 2107 года). Следовательно, начиная с 1 января 2100 года, операционные системы на базе DOS, а также приложения, конвертирующие другие форматы в формат FAT/DOS, могут демонстрировать неожиданное поведение.

Nintendo DS, GameCube Sony PlayStation 4 также позволяют пользователям устанавливать даты только до 2099 года. В случае с Nintendo DS система не будет переводить время дальше 31 декабря 2099 года, тогда как GameCube и PS4 продолжат отсчёт до 2100 года и далее, несмотря на то, что пользователи этих игровых консолей не могут вручную установить дату и время так далеко.

Ещё одна проблема возникнет в конце 28 февраля 2100 года, поскольку 2100-й год не является високосным. Поскольку многие распространенные реализации правил високосных годов являются неполными или чрезмерно упрощёнными, они могут ошибочно считать 2100 год високосным, что приведёт к переходу с 28 февраля 2100 года к 29 февраля 2100 года вместо 1 марта 2100.

Аппаратные часы реального времени DS3231 страдают от проблемы 2100 года, поскольку для хранения года использует только две цифры^[70].

Многие существующие форматы файлов, протоколы связи и интерфейсы приложений используют вариант формата даты Unix time_t, запоминая число секунд с начала эпохи Unix (полночь UTC 1 января 1970 года) в виде беззнакового 32-битного бинарного целого. Это значение переполнится 7 февраля 2106 года в 06:28:16 UTC. То есть, в этот момент число секунд с 1 января 1970 года будет равно FFFFFFFF в шестнадцатеричном формате^[5].

Эта проблема представления данных не затрагивает программы, которые внутренне хранят и обрабатывают системное время как 64-битные знаковые целые числа.

Метки времени в FAT файловых системах, впервые появившихся в 86-DOS 0.42 в 1981 году и использовавшихся в MS-DOS, PC DOS, DR-DOS и т.д., переполнятся к концу 31 декабря 2107 года^[5]. Последняя дата модификации файла (а с 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 году^[5][11][13].

RISC OS хранит даты как сотые доли секунды с 1 января 1900 в пяти байтах (40 бит). Эти данные хранятся внутри системы и отображаются в метаданных файлов^[71]. Эти значение достигают своего предела 3 июня 2248 года в 06:57:57.75 UTC^[5].

Некоторые высокоточные системы хранения времени отсчитывают наносекунды с 1 января 1970 года, используя 64-битное целое число со знаком, которое переполнится 11 апреля 2262 года в 23:47:16 UTC. API UnixNano языка программирования Go является одним из примеров^[72]. К другим примерам относятся объект Timestamp в библиотеке pandas для Python^[73], класс chrono в C++ при установке наносекундной точности^[74], а также таймеры QEMU^[75].

Системы, которые используют строку длиной 10 символов для записи Unix-времени могут иметь проблемы после 20 ноября 2286 года 17:46:39 UTC, что на десять миллиардов секунд позже эпохи Unix^[5].

В ext4, файловой системе по умолчанию во многих дистрибутивах Linux, младшие два бита полей {a,c,m}time_extra используются для расширения полей {a,c,m}time, отодвигая проблему 2038 года до 2446 года^[76]. В этом «дополнительном» 32-битном поле два младших бита расширяют поле секунд до 34-битного знакового целого числа. Старшие 30 бит обеспечивают точность времени до наносекунд. Таким образом, переполнение временных меток произойдет не раньше мая 2446 года^[77].

В масштабе тысяч лет григорианский календарь отстаёт от астрономических сезонов. Это потому, что скорость вращения Земли постепенно уменьшается, что делает каждый день чуть длиннее со временем (см. Приливное ускорение и Дополнительная секунда) в то время как продолжительность года становится более постоянной.

В 19-м столетии, Джон Гершель предложил модификацию грегорианского календаря с 969 високосными днями каждые 4000 лет вместо 970 високосных дней, которые вставил бы григорианский календарь за тот же период^[78]. Это позволило бы сократить среднюю продолжительность года до 365,24225 дней. Предложение Гершеля означало бы, что 4000 год и его кратные стали бы обычными, а не високосными. Несмотря на то, что эта модификация неоднократно предлагалась с тех пор, она так и не была официально принята^[79].

В то время как большинство программного обеспечения (включая Excel, JavaScript и R) сейчас распознают 4000 и 8000 как високосные года (поскольку они делятся на 400), SAS придерживается «правила 4000-го года». Таким образом, при использовании текущего программного обеспечения преобразования дат между SAS и другим программным обеспечением будут рассинхронизироваться после 28 февраля 4000 года^[80][81].

Microsoft Outlook использует 1 января 4501 года в значении «нет» или «пусто»^[5][82][83].

Год 10000 будет первым годом по грегорианскому календарю с пятью знаками. Системы, разрешающие только четыре символа для года, будут иметь проблемы с последующими годами, как и с годами до 10-го тысячелетие до н. э..

По состоянию на 2025 год максимальная поддерживаемая дата для вычислений программой электронных таблиц Microsoft Excel — 31 декабря 9999 года^[84].

Файловые системы оптических дисков ISO 9660 и UDF имеют диапазон дат, заканчивающийся в 9999 году^[85][86].

В языке программирования C# или любом языке, использующем .NET, структура DateTime хранит абсолютное время как число десятых долей микросекунды (10⁻⁷ с, называемых «тиками»^[87]) с полуночи UTC 1 января 1 года нашей эры по пролептическому григорианскому календарю^[88]. Это значение переполнит знаковое 64-битное целое 14 сентября 29228 года в 02:48:05.4775808 UTC^[5][89]. Структуры хранения времени во многих приложениях Microsoft и сервисах имеют разрешение 100 наносекунд, например, тип данных TIME в Power Automate^[86] и параметр TimeSpan в различных командах PowerShell^[90]. Все они столкнутся с аналогичными проблемами. Однако даты после 31 декабря 9999 года в 23:59:59.9999999 UTC считаются «неподдерживаемыми» и операции со временем неизбежно вызовут ошибки, когда расчёты приведут к датам позднее 9999 года^[91].

Аналогично, в операционной системе Windows структура FILETIME запоминает число 100-наносекундных тиков с 1 января 1601 года как 64-битное целое со знаком. Это значение переполнится 14 сентября 30828 года в 02:48:05 UTC, после чего Windows не будет принимать даты да этого дня и будет выводить сообщение «неверное системное время» (англ. invalid system time) в NTFS^[5][92].

Программы, работающие с годами в формате 16-битных значений, могут столкнуться с проблемами при работе с годами 32768 или 65536, в зависимости от того, рассматривается ли год как знаковое или беззнаковое целое число.

В системах, использующих знаковые 16-битные целые, года после 32767 могут быть интерпретированы как отрицательные числа^[5], начиная с −32,768, что может отображаться как 32768 до нашей эры. В системах, использующих беззнаковое 16-битное целое число, проблема, скорее всего, проявится в том, что год 65536 будет показан как год 0^[5][93], или год 65 537 «перевернётся» обратно к году 1.

Архивы статических библиотек, созданные командой ar ar в Unix хранят временные метки в виде строки ASCII, содержащей десятичное число секунд, прошедших с начала эпохи Unix. Эта строка ограничена 12 символами. Значение переполнится 27 сентября 33658 в 01:46:40 UTC, что произойдет через триллион секунд после начала эпохи Unix^[5].

Год 100000 будет первым годом по Грегорианскому календарю с шестью знаками.

JavaScript хранит даты как количество миллисекунд, прошедших с 1 января 1970 года. Даты имеют диапазон ±100,000,000 дней от этого момента, что означает, что программы, написанные на JavaScript с использованием API для работы с датами, не могут хранить даты, выходящие за пределы 13 сентября 275 760 года нашей эры^[5][94].

Системы, запоминающие время в формате Unix в секундах, используя 64-битные целые со знаком, могут представить дату и время до 15:30:08 UTC воскресенья 4 декабря 292.277.026.596 года нашей эры^[5][95][96]. Однако этот год настолько в далёком будущем (значительно превышает предполагаемый срок существования Земли, Солнце и даже некоторые прогнозы продолжительности жизни Вселенной), что упоминается в основном как теоретический интерес, шутка или указание на то, что ранние проблемы, такие как проблема 2038 года, не могут быть по-настоящему «решены» навсегда.

В Microsoft Windows 7, Windows Server 2003, Windows Server 2008 и Windows Vista информация о начале TCP-соединения запоминалась в сотых долях секунды с использованием беззнакового 32-битного целого, что приводило к разрыву TCP-соединения через 497 дней^[97].

Windows 95 и Windows 98 имели проблемы с переполнением а драйвере виртуального устройства VTDAPI.VXD, который использовал беззнаковые 32-битные целые числа для измерения времени работы в миллисекундах. Это значение переполнялось примерно через 49,7 дней, вызывая зависание системы^[98].

До версии 6.0 платформа Microsoft .NET имела баг, который вызывал сбой алгоритма восхождения к вершине для пула потоков периодически после 49,7 дней вследствие переполнения обработки миллисекунд с момента старта^[99].

Самолёты Boeing 787 Dreamliner имели по меньшей мере две программные проблемы, связанные с хранением времени. В 2015 году была зафиксирована ошибка, связанная с тем, что системное время хранилось в сотых долях секунды в 32-битном целом со знаком. Это значение переполнялось через 248 дней, после чего системы управления бортовым генератором выходили из строя, приводя к потере питания самолёта^[100][101].

В 2020 году Федеральное управление гражданской авиации США издало директиву лётной годности, предписывающую операторам 787 полностью выключать свои самолеты перед достижением 51 дня непрерывной работы, поскольку в противном случае системы начнут отображать некорректные данные^[102].

Платформа Arduino предоставляет относительное время с помощью функции millis(). Эта функция возвращает беззнаковое 32-битное целое число, представляющее «миллисекунды с момента запуска», которое будет обнуляться каждые 49 дней. По умолчанию это единственный источник времени, доступный на платформе, и программы должны принимать особые меры для обработки таких обнулений^[103]. Внутренне millis() основана на подсчёте прерываний таймера. Определенные режимы энергосбережения отключают прерывания и, следовательно, останавливают счётчик от продвижения во время сна^[104].

Also, for historic years there might be problems when handling historic events, for example:

• 0 год
• Проблема года 1000
• Проблема года 1414
• Проблема года 1582
• Проблема года 1900

• Гейзенбаг – Программная ошибка, которая выглядит меняющейся при отладке
• Long Now Foundation – Американская некоммерческая организация