Отказ от ответственности

Я только около 20 минут просматривал список сайтов StackExchange, пытаясь выяснить, где это можно опубликовать. Если вы знаете какой-либо сайт более подходящий, пожалуйста, переместите этот вопрос туда. Я публикую это здесь, потому что время Unix заставило меня задуматься.

Итак, как мы все знаем, есть время Unix и есть UTC. Время Unix продолжает тикать, считая секунды - одну секунду в секунду - тогда как UTC старается сохранять время в удобочитаемых для человека форматах, которые мы используем, в соответствии с фазой вращения Земли. Для этого время от времени UTC вставляет високосные секунды.

Поскольку время зависит от силы тяжести, которой подвергается объект, испытывающий время, других видов ускорения и относительной скорости, это приводит к двум вопросам. Давайте сначала пройдемся по простому: где измеряется время Unix? Если Алиса и Боб начинают соглашаться, текущее время составляет 1467932496.42732894722748, когда они находятся в одном и том же месте (секунда, конечно, определяется как 9'192'631'770 циклов излучения, соответствующих переходу между двумя энергетическими уровнями цезия-133 атом в состоянии покоя и при 0 К), испытайте парадокс близнецов из-за того, что Алиса живет на уровне моря, а Боб живет высоко в горах или Алиса живет на северном полюсе, а Боб живет на экваторе, они больше не согласятся. Так как точно определить время Unix?

Вы можете сначала не увидеть проблему с UTC, потому что наверняка все могут договориться, когда Земля завершила орбиту (это, конечно, игнорирование движения континентальной плиты, но я думаю, что мы поняли это довольно хорошо, потому что с помощью GPS можно измерить их движение очень точно, и мы можем предположить, что они находятся в заданном положении в нашей модели и не перемещаются при перемещении континентальных плит), независимо от того, находятся ли они на горе, на уровне моря, на экваторе или на северном полюсе. Могут быть некоторые различия во времени, но они не накапливаются.

Но секунда определяется как 9'192'631'770 циклов излучения, соответствующих переходу между двумя энергетическими уровнями атома цезия-133 в состоянии покоя и при 0 К, а атом цезия-133 не заботится об орбите Земли. Таким образом, UTC решает, куда вставить високосную секунду, но должен быть измеренный или предсказанный сдвиг между фазой земной орбиты и временем, измеренным где-то атомными часами. Где это где то?

Ваш главный вопрос не имеет реального ответа; Время Unix не является реальной шкалой времени и нигде не «измеряется». Это представление UTC, хотя и плохое, потому что в UTC есть моменты, которые он не может представить. Время Unix настаивает на том, чтобы каждый день было 86 400 секунд, но UTC отклоняется от этого из-за високосных секунд.

Что касается вашего более широкого вопроса, есть четыре важных графика времени:

1. UT1 (всемирное время), которое рассчитывается обсерваториями по всему миру, которые измеряют вращение Земли относительно неподвижных звезд. С этими наблюдениями и небольшой математикой мы получаем более современную версию старого среднего времени по Гринвичу, которое основывалось на моменте солнечного полудня в Королевской обсерватории в Гринвиче. Всемирное время рассчитывается организацией под названием IERS (Международная служба вращения Земли и системы отсчета, ранее Международная служба вращения Земли).

2. TAI (Международное атомное время), которое хранится сотнями атомных часов по всему миру, поддерживается национальными органами по стандартизации и тому подобное. Хранители часов, которые вносят вклад в TAI, используют методы передачи времени , чтобы направлять свои часы навстречу друг другу, устраняя любые небольшие ошибки отдельных часов и создавая ансамблевое время; этот ансамбль - TAI, опубликованный Международным бюро мер и весов (BIPM), управляющий системой единиц СИ. Чтобы ответить на ваш вопрос о замедлении времени, TAI определяется как атомное время на уровне моря (на самом деле, на геоиде, который является более изящной версией той же идеи), и каждые часы корректируют влияние собственной высоты.

3. UTC (Всемирное координированное время). UTC был установлен равным десяти секундам после TAI 1 января 1972 года, и с этой даты он движется вперед точно с той же скоростью, что и TAI, за исключением случаев, когда добавляется или вычитается дополнительная секунда. IERS принимает решение объявить високосную секунду, чтобы сохранить разницу в течение 0,9 секунды (на практике, в течение примерно 0,6 секунды; добавленная дополнительная секунда приводит к тому, что разница увеличивается с -0,6 до +0,4). Теоретически, високосные секунды могут быть как положительными, так и отрицательными, но поскольку вращение Земли замедляется по сравнению со стандартом, установленным SI и TAI, отрицательная високосная секунда никогда не была необходима и, вероятно, никогда не будет.

4. Время Unix, которое делает все возможное, чтобы представить UTC как одно число. Каждое время Unix, кратное 86 400, соответствует полуночи UTC. Поскольку не все дни UTC имеют длину 86 400 секунд, а все дни «Unix» есть, существует непримиримая разница, которую нужно каким-то образом исправлять. Там нет времени Unix, соответствующего добавленной високосной секунде. На практике системы либо будут действовать так, как если бы предыдущая секунда происходила дважды (когда метка времени Unix скачет назад на одну секунду, а затем снова продвигается вперед), либо применят метод, такой как скачкообразное смазывание, которое деформирует время в течение более длительного периода времени по обе стороны от вторая секунда В любом случае есть некоторая неточность, хотя по крайней мере второй является монотонным. В обоих случаях,и б не равно ба; это равно ба плюс количество промежуточных високосных секунд .

Поскольку UT1, TAI, UTC и IERS являются всемирными, многонациональными усилиями, не существует единого «где», хотя бюллетени IERS публикуются в Парижской обсерватории, а BIPM также базируется в Париже, и это один из ответов. Организация, которая требует точного и прослеживаемого времени, может указать свою временную базу как что-то вроде «UTC (USNO)», что означает, что их временные метки указаны в UTC и что они получены из времени в Военно-морской обсерватории США, но с учетом проблем, которые Я упоминал о времени Unix, оно в основном несовместимо с таким уровнем точности - у любого, кто имеет дело с действительно точным временем, будет альтернатива времени Unix.

Настройки часов координируются IERS. Они планируют вставку високосной секунды в поток времени по мере необходимости.

От временной шкалы NTP и високосных секунд

Международная служба вращения Земли (IERS) на Парижской обсерватории использует астрономические наблюдения , предоставленные US и другие обсерватории , чтобы определить временные рамки UT1 (штурман) исправленные для нерегулярных вариаций вращения Земли.

Насколько мне известно, 23:59:60 (вторая секунда) и 00:00:00 следующего дня считаются одной и той же секундой в Unix Time.

Время UNIX измеряется на вашем компьютере под управлением UNIX.

Этот ответ предполагает, что вы будете знать, что такое Всемирное координированное время (UTC), Международное атомное время (TAI) и секунда SI. Их объяснение выходит далеко за рамки Unix и Linux Stack Exchange. Это не обмен физическими стеками или астрономическими.

Аппаратное обеспечение

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

• Где-то есть программируемый интервальный таймер (PIT), который может быть запрограммирован для подсчета заданного количества колебаний и запуска прерывания для центрального процессора.
• На центральном процессоре есть счетчик циклов, который просто считает 1 для каждого выполняемого цикла команд.

Теория работы, в очень широком смысле

Ядро операционной системы использует PIT для генерации тиков . Он настраивает PIT на свободный ход, подсчитывая правильное количество колебаний за интервал времени, скажем, одну сотую секунды, генерируя прерывание, а затем автоматически сбрасывает счет для повторного запуска. Существуют варианты этого, но по сути это вызывает прерывание тика с фиксированной частотой.

В программном обеспечении ядро ​​увеличивает счетчик каждый тик. Он знает частоту тиков, потому что он запрограммировал PIT в первую очередь. Так что он знает, сколько тиков составляют секунды. Он может использовать это, чтобы знать, когда увеличивать счетчик, который считает секунды. Эта последняя идея ядра "UNIX Time". Действительно, он просто считает вверх со скоростью один раз в секунду, если оставить его своим собственным устройствам.

Это усложняют четыре вещи, которые я собираюсь представить в общих чертах.

Аппаратное обеспечение не идеально. PIT, в паспорте которого указано, что частота генератора составляет N Герц, вместо этого может иметь частоту (скажем) N 00002 Герц с очевидными последствиями.

Эта схема очень плохо взаимодействует с управлением питанием, потому что процессор просыпается сотни раз в секунду, делая чуть больше, чем просто увеличивая число в переменной. Таким образом, некоторые операционные системы имеют так называемые «тикающие» конструкции. Вместо того, чтобы заставить PIT отправлять прерывание для каждого тика, ядро ​​вычисляет (из планировщика низкого уровня), сколько тиков будет проходить без исчерпания квантов потока, и программирует PIT для подсчета такого количества тиков в Будущее перед выдачей тикового прерывания. Он знает, что затем должен записать прохождение N тиков при следующем тиковом прерывании, вместо 1 тика.

Прикладное программное обеспечение имеет возможность изменять текущее время ядра. Он может увеличить значение или уменьшить значение. Поворот включает в себя настройку количества тиков, которые должны пройти, чтобы увеличить счетчик секунд. Таким образом, счетчик секунд не обязательно будет считаться со скоростью один раз в секунду в любом случае , даже при условии идеальных осцилляторов. Шаг включает в себя просто запись нового числа в счетчик секунд, что обычно не происходит до 1 СИ секунды с момента последней секунды.

Современные ядра не только считают секунды, но и считают наносекунды. Но смешно и часто совершенно невозможно сделать прерывание по такту раз в наносекунду. Это где такие вещи, как счетчик цикла вступают в игру. Ядро запоминает значение счетчика циклов в каждую секунду (или на каждом тике) и может вычислить из текущего значения счетчика, когда что-то хочет узнать время в наносекундах, сколько наносекунд должно пройти с последней секунды (или поставить галочку). Опять же, однако, управление энергопотреблением и тепловым режимом разрушает эту ситуацию, поскольку частота цикла команд может меняться, поэтому ядра работают так, как будто полагаются на дополнительное оборудование, например, на высокоточный таймер событий (HPET).

Язык Си и POSIX

Стандартная библиотека языка Си описывает время в терминах непрозрачного типа, time_t, типа структуры tmс различными заданными полями, а также различные функции , такие как библиотеки time(), mktime(), и localtime().

Вкратце: на языке С самого всего в гарантирует , что time_tявляется одним из доступных числовых типов данных , и что единственный надежный способ разницы во времени высчитывает является difftime()функцией. Это стандарт POSIX, который обеспечивает более строгие гарантии, который time_tна самом деле является одним из целочисленных типов и что он отсчитывает секунды с начала эпохи . Это также стандарт POSIX, который определяет timespecтип структуры.

time()Функция иногда описывается как системный вызов. На самом деле, это не было системным вызовом во многих системах в течение достаточно долгого времени, в настоящее время. Например, во FreeBSD системный вызов, лежащий в основе clock_gettime(), имеет различные «часы», которые измеряются в секундах или секундах + наносекунды различными способами. Именно этот системный вызов, с помощью которого прикладное программное обеспечение читает UNIX Time из ядра. (Соответствующий clock_settime()системный вызов позволяет им шагнуть, а adjtime()системный вызов позволяет им убить его.)

Многие люди разворачивают стандарт POSIX с очень четкими и точными утверждениями о том, что он предписывает. Такие люди чаще всего не читают стандарт POSIX. Как изложено в его обосновании, идея подсчета «секунд после эпохи», то есть фразы, которую использует стандарт, намеренно не указывает, что секунды POSIX имеют ту же длину, что и секунды СИ, и что результат gmtime()«обязательно» UTC, несмотря на свою внешность ". Стандарт POSIX преднамереннодостаточно свободно, чтобы можно было, скажем, использовать систему UNIX, в которую входит администратор, и вручную исправляет настройки високосных секунд, переустанавливая часы через неделю после того, как они произошли. Действительно, логическое обоснование указывает на то, что он намеренно достаточно свободен для размещения систем, в которых часы были намеренно установлены неправильно на некоторое время, отличное от текущего времени UTC.

UTC и TAI

Интерпретация времени UNIX, полученного от ядра, зависит от библиотечных процедур, выполняемых в приложениях. POSIX определяет идентичность между временем ядра и «временем разбивки» в struct tm. Но, как однажды указал Даниэль Бернштейн, издание стандарта 1997 года сделало эту идентичность смущающей ошибкой, запутав правило григорианского календаря високосного года (то, чему учат школьники), так что расчет был ошибочным с 2100 года. «Больше чести в нарушении, чем соблюдения» - фраза, которая легко приходит на ум.

И это действительно так. Некоторые системы в настоящее время основывают эту интерпретацию на библиотечных процедурах, написанных Артуром Дэвидом Олсоном, которые обращаются к печально известной «базе данных часовых поясов Олсона», обычно кодируемой в файлах базы данных в /usr/share/zoneinfo/. Система Олсона имела два режима:

• Считается, что "секунды с начала эпохи" ядра подсчитывают секунды UTC с 1970-01-01 00:00:00 UTC, за исключением високосных секунд. Это использует posix/набор файлов базы данных часового пояса Олсона. Во всех днях по 86400 секунд ядра и никогда не бывает 61 секунды в минуту, но они не всегда являются длиной SI-секунды, и часы ядра должны вращаться или пошагово, когда происходят високосные секунды.
• Считается, что «секунды с начала эпохи» ядра подсчитывают секунды TAI с 1970-01-01 00:00:10 TAI. Это использует right/набор файлов базы данных часового пояса Олсона. Секунды ядра имеют длительность 1 SI в секунду, и тактовые частоты ядра никогда не нуждаются в повороте или пошаговом переключении для настройки високосных секунд, но время разбивки может иметь значения, такие как 23:59:60, а дни не всегда имеют длину 86400 секунд ядра.

М. Бернштейн написал несколько инструментов, включая его daemontoolsнабор инструментов, которые требовались, right/потому что они просто добавили 10 к, time_tчтобы получить секунды TAI с 1970-01-01 00:00:00 TAI. Он задокументировал это на странице руководства.

Это требование было (возможно , неосознанно) наследуется , такие как наборы инструментов daemontools-encoreи runitи Феликса фон Leitner - х libowfat. Например, используйте Bernsteinmultilog , Guentermultilog или Papesvlogd с posix/конфигурацией Olson , и все метки времени TAI64N будут (на момент написания этого) на 26 секунд отставать от фактического количества секунд TAI с 1970-01-01 00:00:10 TAI.

Мы с Лораном Берко обратились к этому в s6 и nosh, хотя мы и использовали разные подходы. M. Bercot's tai_from_sysclock()полагается на флаг времени компиляции. Nosh инструменты, сделки в TAI64N взгляд на TZи TZDIRпеременных окружения для автоопределения posix/и right/если они могут.

Интересно, FreeBSD документов time2posix()и posix2time()функции , которые позволяют эквивалент Olson right/режима с , time_tкак TAI секунды. Однако они явно не включены.

Снова…

Время UNIX измеряется на вашем компьютере под управлением UNIX осцилляторами, содержащимися в аппаратном обеспечении вашего компьютера. Это не использует SI секунд; это не UTC, хотя внешне это может напоминать; и это намеренно позволяет вашим часам ошибаться.

дальнейшее чтение

• Даниэль Дж. Бернштейн. Время UTC, TAI и UNIX . cr.yp.to.
• Даниэль Дж. Бернштейн. tai64nlocal, DAEMON Tools. cr.yp.to.
• « Секунды с эпохи ». Одиночная версия спецификации UNIX 2 . 1997. Открытая группа.
• « Секунды с эпохи (обоснование) ». Базовые спецификации Выпуск 6 . 2004. IEEE 1003.1. Открытая группа.
• Дэвид Мадор (2010-12-17). Unix скачок второй беспорядок .
• time2posix, Руководство FreeBSD 10.3. § 3
• /physics/45739/
• /astronomy/11840/