Это не новость, но вопрос всплывает достаточно часто, поэтому я считаю, что проблему нужно объяснить кратко. Люди, и я в том числе, обычно говорят, что время POSIX, также известное как время Unix — это количество of секунд, прошедших с эпохи Unix, то есть с 00:00:00 1970-01-01.
Но это не так. Точнее, не так в смысле, подразумеваемом большинством. Например, сейчас у меня на часах 2024-12-25, 18:51:26 UTC. Время POSIX равно 1735152686. Прошло 1735152713 секунд с эпохи POSIX. Число времени POSIX на двадцать семь секунд меньше.
Причина в том, что время POSIX вычисляется в IEEE 1003.1 из Coordinated Universal Time. Стандарт предполагает, что каждый день — это ровно 86400 секунд. Цитата:
Функция time() возвращает значение времени в секундах с Эпохи.
Что определяется следующим образом:
секунды с Эпохи. Значение, интерпретируемое как количество секунд между указанным временем и Эпохой. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900(tm_year)) is related to a time represented as seconds since the Epoch according to the expression below.
Если год < 1970 или значение отрицательное, то соотношение неопределено. Если год ≥ 1970 и значение неотрицательное, то значение связано с Coordinated Universal Time следующим выражением:
tm_sec + tm_min 60 + tm_hour 3600 + tm_yday 86400 + (tm_year-70) 31536000 + ((tm_year — 69) / 4) * 86400
День не состоит из 86400 секунд и его длина меняется со временем. Чтобы дни UTC не слишком расходились с астрономическими днями, астрономы периодически объявляют в UTC дополнительную секунду. Следовательно, каждые несколько лет время POSIX отскакивает назад, наводя настоящий хаос. Когда-то оно может прыгнуть вперёд.
Археология
В Приложении B к IEEE 1003 есть потрясающее описание дополнительных секунд:
Концепция дополнительных секунд добавлена ради точности; на момент публикации стандарта с 1 января 1970 было добавлено 14 дополнительных секунд. Эти 14 секунд игнорируются, чтобы можно было вычислять разницу времени простым и совместимым образом.
Я тоже люблю закрывать на что-то глаза, чтобы упростить себе жизнь. Авторы стандарта знали, что «секунды с эпохи» на самом деле не были секундами после эпохи. И они это признают:
В большинстве систем понятие времени — это постоянно растущее значение, поэтому это значение должно увеличиваться даже во время дополнительных секунд. Однако большинство систем не только не отслеживает дополнительные секунды, но и большинство систем, вероятно, не синхронизированы с каким-либо источником стандартного времени. Поэтому недопустимо требовать, чтобы время, представленное как секунды с Эпохи, точно представляло количество секунд между временем источника и Эпохой.
Достаточно требования, чтобы приложениям можно было обрабатывать это время, как будто оно представляет количество секунд между временем источника и Эпохой. Изготовитель системы и администратор системы должны обеспечить максимально близкое необходимое соответствие между временем источника и Эпохой для приложения, выполняемого в этой системе...
Думаю, по этому пункту возникли некоторые споры. The appendix punts, saying that vendors and administrators must make time align “as closely as necessary”, and that “this value should increase even during leap seconds”. Последнее достижимо, но первое, мне кажется, невозможно: стандарт требует, чтобы часы POSIX отличались на двадцать семь секунд.
Согласованная интерпретация секунд с Эпохи может быть критичной в определённых типах распределённых приложений, использующих такие метки времени для синхронизации событий. Прирост дополнительных секунд в стандарте времени непредсказуем. Количество дополнительных секунд с Эпохи, вероятно, увеличится. Стандарту важнее синхронизация времени между приложениями в астрономически коротких промежутках, и Рабочая группа ожидает, что в будущем эти проблемы станут ещё более критичными.
В каком-то смысле, произошло нечто обратное. Синхронизация времени всегда сбита, поэтому при небольших смещениях времени системы в общем случае функционируют (хотя и некорректно). Но дополнительные секунды случаются редко, а линейность, образ которой вызывается фразой «секунды с эпохи», насколько глубоко въелась в наше интуитивное понимание, что в ПО могут накапливаться серьёзные незамечаемые баги. Пока спустя несколько лет одна из таких дополнительных секунд не обрушит большую часть Интернета.
Как решить эту проблему
Если вам просто нужно вычислить время между двумя событиями на одном компьютере, то используйте CLOCK_MONOTONIC или, что ещё лучше, CLOCK_BOOTTIME. Если вам не нужно обмениваться метками времени с другими системами, подразумевающими использование времени POSIX, то используйте TAI, GPS или, возможно, LORAN. Если же вам нужно приблизительное согласование с другими системами, использующими метки времени POSIX, то «размазывайте» дополнительные секунды на более широкое временное окно. Библиотеки наподобие t-a-i разработчика qntm позволяют выполнять преобразования между POSIX и TAI.
Кроме того, постоянно проводятся работы по устранению дополнительных секунд; возможно, это удастся сделать к 2035 году. Для этого потребуются дополнительные труды по встраиванию таблиц преобразований во все системы, полагающиеся на допущение «в одном дне ровно 86400 секунд», однако это и упростит ответы на вопросы типа «сколько секунд прошло между этими двумя моментами». По крайней мере, для моментов времени после 2035 года!
