Unix время и секунды прыжка

Что касается времени Unix (POSIX), Wikipedia говорит:

Из-за его обработки секунд прыжка он не является ни линейным представлением времени, ни истинным представлением UTC.

Но команда Unix date, похоже, не знает об этом на самом деле

$ date -d '@867715199' --utc
Mon Jun 30 23:59:59 UTC 1997
$ date -d '@867715200' --utc
Tue Jul  1 00:00:00 UTC 1997

В то время как там должен быть прыжок второй в Mon Jun 30 23:59:60 UTC 1997.

Означает ли это, что только команда date игнорирует секунды прыжка, в то время как понятие времени Unix не работает?

Ответ 1

Количество секунд в день фиксируется с помощью отметок времени Unix.

Число времени Unix в эпоху Unix равно нулю и увеличивается на ровно 86400 в день с эпохи.

Таким образом, он не может представлять високосные секунды. ОС замедлит время, чтобы приспособиться к этому. Временные метки просто отсутствуют в том, что касается меток времени Unix.

Ответ 2

Unix-время прост в работе, но некоторые временные метки не являются реальными, а некоторые временные метки не уникальные.

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

Обоснование для unix time: оно определено так, что с ним легко работать. Добавление поддержки для прыжков в стандартные библиотеки очень сложно. Например, вы хотите представить 1 января 2050 года в базе данных. Никто не знает, сколько секунд осталось в UTC! Дата не может быть сохранена как временная метка UTC, потому что IAU не знает, сколько секунд мы должны будем добавить в следующие десятилетия (они так же хороши, как и случайные). Итак, как программист может выполнить арифметику даты, когда время, которое пройдет между любыми двумя датами в будущем, не известно до года или двух раньше? Время Unix прост: мы знаем метку времени от 1 января 2050 года (а именно, 80 лет * # в секундах в год). UTC очень сложно работать круглый год, тогда как время unix с трудом работает в тот момент, когда происходит прыжок.

Для чего это стоит, я никогда не встречал программиста, который согласен со скачкообразными секундами. Они должны быть явно отменены.

Ответ 3

Поскольку оба других ответа содержат много вводящей в заблуждение информации, я добавлю это.

Томас прав, что количество секундных отметок времени эпохи Unix фиксировано. Это означает, что в дни, когда существует високосная секунда, секунда перед полуночью (61 секунда UTC минуты до полуночи) получает ту же метку времени, что и предыдущая секунда.

Эта временная метка "воспроизводится", если хотите. Таким образом, та же самая метка времени Unix будет использоваться в течение двух секунд реального мира. Это также означает, что если вы получаете дробные эпохи Unix, повторяется вся секунда.

X86399.0, X86399.5, X86400.0, X86400.5, X86400.0, X86400.5, затем X86401.0.

Таким образом, время Unix не может однозначно представлять високосные секунды - метка високосной секунды также является меткой времени для предыдущей секунды реального мира.

Ответ 4

Здесь и в других местах идет много дискуссий о високосных секундах, но это не сложная проблема, поскольку она не имеет ничего общего с UTC, или GMT, или UT1, или TAI, или любым другим стандартом времени. Время POSIX (Unix) по определению соответствует времени, указанному в стандарте IEEE Std 1003.1 "POSIX", доступно здесь.

Стандарт однозначен: время POSIX не включает високосные секунды.

Всемирное координированное время (UTC) включает високосные секунды. Однако во время POSIX (секунды с начала эпохи) високосные секунды игнорируются (не применяются), чтобы обеспечить простой и совместимый метод вычисления разницы во времени. Таким образом, время POSIX не всегда совпадает с UTC, несмотря на его внешний вид.

Стандарт подробно описывает однозначно, что время POSIX не включает в себя дополнительные секунды, в частности:

Практически невозможно установить, что соответствующая реализация должна иметь фиксированную связь с какими-либо конкретными официальными часами (рассмотрим изолированные системы или системы, выполняющие "перезапуски" путем установки часов на произвольное время).

Поскольку високосные секунды определяются комитетом, включать в високосные секунды время POSIX не просто "плохая идея", это невозможно, учитывая, что стандарт допускает соответствующие реализации, которые не имеют доступа к сети.

В другом месте этого вопроса @Pacerier сказал, что время POSIX включает в себя високосные секунды, и что каждое время POSIX может соответствовать более чем одному времени UTC. Хотя это, безусловно, одна из возможных интерпретаций метки времени POSIX, это никоим образом не определено стандартом. Его аргументы в значительной степени сводятся к ласка слов, которые не относятся к стандарту, который определяет время POSIX.

Теперь все усложняется. Как указано в стандарте, время POSIX может не совпадать с временем UTC:

Таким образом, время POSIX не всегда совпадает с UTC, несмотря на его внешний вид.

Однако на практике это так. Чтобы понять проблему, вы должны понимать стандарты времени. GMT и UT1 основаны на астрономическом положении Земли во Вселенной. TAI основывается на фактическом количестве времени, которое проходит во вселенной, измеренном физическими (атомными) реакциями. В TAI каждая секунда является "секундой СИ", которые все имеют одинаковую длину. В UTC каждая секунда является секундой SI, но при необходимости добавляются дополнительные секунды, чтобы перенастроить часы с точностью до 0,9 секунды по Гринвичу /UT1. Стандарты времени по Гринвичу и UT1 определяются эмпирическими измерениями положения и движения Земли во Вселенной, и эти эмпирические измерения невозможно предсказать никакими средствами (ни научной теорией, ни приближением). Таким образом, високосные секунды также непредсказуемы.

Теперь стандарт POSIX также определяет, что все временные метки POSIX должны быть совместимы (означать одно и то же) в разных реализациях. Одно решение для всех - согласиться с тем, что каждая секунда POSIX равна одной секунде SI, и в этом случае время POSIX эквивалентно TAI (с заданной эпохой), и никому не нужно связываться ни с кем, кроме их атомных часов. Однако мы этого не сделали, вероятно, потому, что хотели, чтобы временные метки POSIX были временными метками UTC.

Используя очевидную лазейку в стандарте POSIX, реализации намеренно замедляют или ускоряют секунды - так, чтобы время POSIX больше не использовало SI секунд - чтобы оставаться синхронизированным со временем UTC. При чтении стандарта становится ясно, что это было не то, что было задумано, поскольку этого нельзя сделать с изолированными системами, которые поэтому не могут взаимодействовать с другими машинами (их временные метки без високосных секунд означают что-то другое для других машин с високосными секундами). Читайте:

[...] важно, чтобы интерпретация названий времени и секунд, начиная с эпохальных значений, была согласованной во всех соответствующих системах; то есть важно, чтобы все соответствующие системы интерпретировали "536457599 секунд с начала эпохи" как 59 секунд, 59 минут, 23 часа 31 декабря 1986 года, независимо от точности представления системы о текущем времени. Выражение дано для обеспечения последовательной интерпретации, а не для попытки указать календарь. [...] Эта неопределенная секунда номинально равна секунде Международной системы (СИ).

"Лазейка", допускающая такое поведение:

Обратите внимание, что в качестве практического следствия длина секунды, измеренная некоторым внешним стандартом, не указана.

Таким образом, реализации злоупотребляют этой свободой, намеренно изменяя ее на нечто, что по определению не может быть совместимым между изолированными или неучастными системами. Альтернативно, реализация может просто повторять POSIX раз, как если бы времени не прошло. Смотрите этот ответ Unix StackExchange для получения подробной информации обо всех современных реализациях.

Фу, это все сбивало с толку... Настоящая головоломка!