stringtranslate.com

время Unix

Текущее время Unix
1730250518( очистить кэш страниц для обновления )
2024-10-30T01:08:38+00:00
Время Unix прошло1 000 000 000 секунд 09.09.2001T01:46:40Z. [1] Это событие было отмечено в Копенгагене, Дания, на вечеринке, организованной датской группой пользователей UNIX в 03:46:40 по местному времени.

Время Unix [a] — это представление даты и времени, широко используемое в вычислительной технике . Оно измеряет время по количеству невисокосных секунд , прошедших с 00:00:00 UTC 1 января 1970 года, эпохи Unix . В современных вычислениях значения иногда хранятся с более высокой степенью детализации , например, микросекундами или наносекундами .

Время Unix возникло как системное время операционных систем Unix . Оно стало широко использоваться в других компьютерных операционных системах , файловых системах , языках программирования и базах данных .

Определение

В настоящее время время Unix определяется как количество секунд без учета високосных, прошедших с 00:00:00  UTC в четверг, 1 января 1970 года, что называется эпохой Unix . [3] Время Unix обычно кодируется как целое число со знаком .

Время Unix0 — это точно полночь UTC 1 января 1970 года, при этом время Unix увеличивается на 1 за каждую невисокосную секунду после этого. Например, 00:00:00  UTC 1 января 1971 года представлено в Unix-времени как31 536 000. Отрицательные значения в системах, которые их поддерживают, указывают время до эпохи Unix, причем значение уменьшается на 1 за каждую невисокосную секунду до эпохи. Например, 00:00:00  UTC 1 января 1969 года представлено в Unix-времени как−31 536 000. Каждый день в Unix-времени состоит ровно из86 400 секунд.

Время Unix иногда называют временем эпохи . Это может ввести в заблуждение, поскольку время Unix — не единственная система времени, основанная на эпохе, а эпоха Unix — не единственная эпоха, используемая другими системами времени. [5]

Високосные секунды

Время Unix отличается как от Всемирного координированного времени (UTC), так и от Международного атомного времени (TAI) в обработке дополнительных секунд . UTC включает дополнительные секунды, которые корректируют расхождение между точным временем, измеренным атомными часами , и солнечным временем , связанным с положением Земли по отношению к Солнцу. Международное атомное время (TAI), в котором каждый день точно86 400 секунд, игнорирует солнечное время и постепенно теряет синхронизацию с вращением Земли со скоростью примерно одну секунду в год. В Unix-времени каждый день содержит ровно86 400 секунд. Каждая високосная секунда использует временную метку секунды, которая непосредственно предшествует или следует за ней. [3]

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

Когда появляется дополнительная секунда , день UTC не совпадает с днем86 400 секунд и номер времени Unix (который всегда увеличивается ровно на86 400 каждый день) испытывает разрыв . Високосные секунды могут быть положительными или отрицательными. Отрицательная високосная секунда никогда не объявлялась, но если бы она была, то в конце дня с отрицательной високосной секундой число времени Unix подскочило бы на 1 к началу следующего дня. Во время положительной високосной секунды в конце дня, что происходит в среднем примерно каждые полтора года, число времени Unix непрерывно увеличивается к следующему дню в течение високосной секунды, а затем в конце високосной секунды подскочило бы на 1 (возвращаясь к началу следующего дня). Например, вот что произошло в строго соответствующих POSIX.1 системах в конце 1998 года:

Числа времени Unix повторяются в секунде, следующей сразу за положительной дополнительной секундой. Число времени UnixТаким образом, 1 483 228 800 неоднозначно: оно может относиться либо к началу секунды координации (2016-12-31 23:59:60), либо к ее концу, на одну секунду позже (2017-01-01 00:00:00). В теоретическом случае, когда возникает отрицательная секунда координации, никакой неоднозначности не возникает, но вместо этого существует диапазон чисел времени Unix, которые вообще не относятся ни к какой точке времени UTC.

Часы Unix часто реализуются с другим типом обработки положительной секунды координации, связанным с сетевым протоколом времени (NTP). Это приводит к системе, которая не соответствует стандарту POSIX. Подробности см. в разделе ниже, посвященном NTP.

При работе с периодами, которые не охватывают високосную секунду UTC, разница между двумя числами времени Unix равна продолжительности периода в секундах между соответствующими точками во времени. Это распространенный вычислительный метод. Однако, когда возникают високосные секунды, такие вычисления дают неверный ответ. В приложениях, где требуется такой уровень точности, необходимо сверяться с таблицей високосных секунд при работе со временем Unix, и часто предпочтительнее использовать другую кодировку времени, которая не страдает от этой проблемы.

Число времени Unix легко преобразуется обратно во время UTC путем взятия частного и модуля числа времени Unix по модулю86 400 . Частное — это количество дней с начала эпохи, а модуль — это количество секунд с полуночи UTC в этот день. Если дано число времени Unix, которое неоднозначно из-за положительной секунды координации, этот алгоритм интерпретирует его как время сразу после полуночи. Он никогда не генерирует время, которое находится в течение секунды координации. Если дано число времени Unix, которое недействительно из-за отрицательной секунды координации, он генерирует столь же недействительное время UTC. Если эти условия существенны, необходимо обратиться к таблице секунд координации, чтобы обнаружить их.

Вариант на основе несинхронного сетевого протокола времени

Обычно часы Unix в стиле Миллса реализуются с обработкой секунды координации, не синхронной с изменением номера времени Unix. Номер времени сначала уменьшается там, где должен был произойти скачок, а затем он переходит на правильное время через 1 секунду после скачка. Это упрощает реализацию и описано в статье Миллса. [6] Вот что происходит при положительной секунде координации:

Это можно правильно расшифровать, обратив внимание на переменную состояния секунды високосного периода, которая однозначно указывает, был ли уже выполнен скачок. Изменение переменной состояния синхронно с скачком.

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

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

Логика декодирования, необходимая для работы с этим стилем часов Unix, также будет правильно декодировать гипотетические часы, соответствующие POSIX, используя тот же интерфейс. Это будет достигнуто путем указания состояния TIME_INS в течение всей вставленной секунды координации, а затем указания TIME_WAIT в течение всей следующей секунды при повторении подсчета секунд. Это требует синхронной обработки секунд координации. Это, вероятно, лучший способ выразить время UTC в форме часов Unix через интерфейс Unix, когда базовые часы принципиально не беспокоятся о секундах координации.

Вариант, который учитывает високосные секунды

Другой, гораздо более редкий, несоответствующий требованиям вариант ведения времени в Unix подразумевает увеличение значения для всех секунд, включая високосные секунды; [7] некоторые системы Linux настроены таким образом. [8] Время, сохраняемое таким образом, иногда называют «TAI» (хотя временные метки могут быть преобразованы в UTC, если значение соответствует времени, когда известна разница между TAI и UTC), в отличие от «UTC» (хотя не все значения времени UTC имеют уникальную ссылку в системах, которые не учитывают високосные секунды). [8]

Поскольку в TAI нет дополнительных секунд, а каждый день TAI длится ровно 86400 секунд, эта кодировка на самом деле является чистым линейным подсчетом секунд, прошедших с 1970-01-01T00:00:10  TAI. Это значительно упрощает арифметику временных интервалов. Значения времени из этих систем не страдают от неоднозначности, которая свойственна строго соответствующим системам POSIX или системам, управляемым NTP.

В этих системах необходимо обратиться к таблице дополнительных секунд для правильного преобразования между UTC и представлением псевдо-Unix-времени. Это напоминает способ, которым таблицы часовых поясов должны быть проверены для преобразования в гражданское время и обратно ; база данных часовых поясов IANA включает информацию о дополнительных секундах, и пример кода, доступный из того же источника, использует эту информацию для преобразования между временными метками на основе TAI и местным временем. Преобразование также сталкивается с проблемами определения до начала 1972 года текущей формы UTC (см. раздел Основа UTC ниже).

Эта система, несмотря на внешнее сходство, не является временем Unix. Она кодирует время со значениями, которые отличаются на несколько секунд от значений времени POSIX. Версия этой системы, в которой эпоха была 1970-01-01T00:00:00  TAI вместо 1970-01-01T00:00:10  TAI, была предложена для включения в ISO C's time.h, но в 2011 году была принята только часть UTC. [9] Однако A tai_clockсуществует в C++20.

Представляя число

Число времени Unix может быть представлено в любой форме, способной представлять числа. В некоторых приложениях число просто представлено текстуально как строка десятичных цифр, что вызывает лишь незначительные дополнительные проблемы. Однако некоторые двоичные представления времени Unix особенно значимы.

Тип данных Unix time_t, представляющий момент времени, на многих платформах представляет собой знаковое целое число , традиционно 32- битное (но см. ниже), напрямую кодирующее число времени Unix, как описано в предыдущем разделе. Знаковое 32-битное значение охватывает около 68 лет до и после эпохи 1970-01-01. Минимальная представимая дата — пятница 1901-12-13, а максимальная представимая дата — вторник 2038-01-19. Через секунду после 2038-01-19T03:14:07Z это представление переполнится, что известно как проблема 2038 года . 

В некоторых новых операционных системах time_tбыл расширен до 64 бит. Это расширяет время, представляемое примерно до 292,3 миллиарда лет в обоих направлениях, что более чем в двадцать раз превышает нынешний возраст Вселенной .

Первоначально существовали некоторые разногласия по поводу того, должен ли Unix time_tбыть знаковым или беззнаковым. Если беззнаковый, его диапазон в будущем будет удвоен, откладывая 32-битное переполнение (на 68 лет). Однако тогда он не сможет представлять время до эпохи. Консенсус заключается в том, чтобы time_tбыть знаковым, и это обычная практика. Платформа разработки программного обеспечения для версии 6 операционной системы QNX имеет беззнаковый 32-битный time_t, хотя более старые выпуски использовали знаковый тип.

Спецификации POSIX и Open Group Unix включают стандартную библиотеку C , которая включает типы времени и функции, определенные в заголовочном файле. Стандарт ISO C утверждает, что это должен быть арифметический тип, но не предписывает какой-либо конкретный тип или кодировку для него. POSIX требует, чтобы это был целочисленный тип, но не предписывает, чтобы он был знаковым или беззнаковым.<time.h>time_ttime_t

Unix не имеет традиции прямого представления нецелых чисел времени Unix в виде двоичных дробей. Вместо этого время с точностью до секунды представляется с использованием составных типов данных , состоящих из двух целых чисел, первое из которых — a time_t(целая часть времени Unix), а второе — дробная часть числа времени в миллионных (в struct timeval) или миллиардных (в struct timespec). [10] [11] Эти структуры предоставляют формат данных с фиксированной точкой на основе десятичной дроби , который полезен для некоторых приложений и тривиален для преобразования для других.

на основе UTC

Текущая форма UTC с дополнительными секундами определена только с 1 января 1972 года. До этого, с 1 января 1961 года, существовала более старая форма UTC, в которой не только время от времени были временные шаги, которые были нецелыми числами секунд, но и секунда UTC была немного длиннее секунды SI и периодически изменялась, чтобы непрерывно приближаться к вращению Земли. До 1961 года не было UTC, а до 1958 года не было широко распространенного атомного хронометража ; в эти эпохи использовалось некоторое приближение GMT ​​(основанное непосредственно на вращении Земли) вместо атомной шкалы времени. [ необходима цитата ]

Точное определение времени Unix как кодировки UTC не вызывает споров только применительно к современной форме UTC. Эпоха Unix, предшествовавшая началу этой формы UTC, не влияет на ее использование в эту эпоху: количество дней с 1 января 1970 года (эпоха Unix) по 1 января 1972 года (начало UTC) не вызывает вопросов, и количество дней — это все, что имеет значение для времени Unix.

Значение значений времени Unix ниже+63 072 000 (т. е. до 1 января 1972 г.) точно не определено. Основой такого времени Unix лучше всего считать неопределенное приближение UTC. Компьютеры той эпохи редко имели часы, установленные достаточно точно, чтобы в любом случае предоставлять значимые метки времени с точностью до секунды. Время Unix не является подходящим способом представления времени до 1972 г. в приложениях, требующих точности до секунды; такие приложения должны, по крайней мере, определять, какую форму UT или GMT они используют.

С 2009 года рассматривается возможность прекращения использования дополнительных секунд в гражданском времени. [12] Вероятным способом реализации этого изменения является определение новой шкалы времени, называемой Международным временем [ требуется ссылка ] , которая изначально соответствует UTC, но впоследствии не имеет дополнительных секунд, таким образом оставаясь на постоянном смещении относительно TAI. Если это произойдет, то, вероятно, время Unix будет перспективно определяться в терминах этой новой шкалы времени, а не UTC. Неопределенность относительно того, произойдет ли это, делает перспективное время Unix не менее предсказуемым, чем оно уже есть: если бы UTC просто не имело дополнительных дополнительных секунд, результат был бы тем же.

История

Самые ранние версии времени Unix имели 32-битное целое число, увеличивающееся с частотой 60  Гц , что соответствовало частоте системных часов на оборудовании ранних систем Unix. Метки времени, сохраненные таким образом, могли представлять только диапазон чуть более двух с четвертью лет. Эпоха, от которой отсчитывался счет, была изменена с выпусками Unix, чтобы предотвратить переполнение, и в начале разработки Unix в качестве эпох использовались полночь 1 января 1971 года и 1 января 1972 года. Ранние определения времени Unix также не содержали часовых поясов. [13] [14]

Текущая эпоха 1 января 1970 00:00:00 UTC была выбрана инженерами Unix произвольно, поскольку считалась удобной для работы. Точность была изменена на подсчет в секундах, чтобы избежать кратковременного переполнения. [1]

Когда был написан POSIX.1 , встал вопрос о том, как точно определить time_tв условиях високосных секунд. Комитет POSIX рассматривал вопрос о том, должно ли время Unix оставаться, как предполагалось, линейным подсчетом секунд с начала эпохи за счет сложности преобразований с гражданским временем или представлением гражданского времени за счет непоследовательности вокруг високосных секунд. Компьютерные часы той эпохи не были достаточно точно установлены, чтобы сформировать прецедент в ту или иную сторону.

Комитет POSIX был склонен к аргументам против сложности библиотечных функций [ требуется ссылка ] и твердо определил время Unix простым способом в терминах элементов времени UTC. Это определение было настолько простым, что оно даже не охватывало все правило високосного года григорианского календаря и делало 2100 год високосным.

В издании POSIX.1 2001 года было исправлено ошибочное правило високосного года в определении времени Unix, но сохранено основное определение времени Unix как кодировки UTC, а не линейной шкалы времени. С середины 1990-х годов компьютерные часы обычно устанавливаются с достаточной точностью, чтобы это имело значение, и чаще всего они устанавливаются с использованием определения времени Unix на основе UTC. Это привело к значительной сложности в реализациях Unix и в сетевом протоколе времени для выполнения шагов в числе времени Unix всякий раз, когда возникают високосные секунды. [ необходима цитата ]

Использование

Время Unix широко применяется в вычислительной технике за пределами своего первоначального применения в качестве системного времени для Unix . Время Unix доступно практически во всех API системного программирования, включая те, которые предоставляются как операционными системами на основе Unix, так и не-Unix . Почти все современные языки программирования предоставляют API для работы со временем Unix или преобразования его в другую структуру данных. Время Unix также используется как механизм для хранения временных меток в ряде файловых систем , форматов файлов и баз данных .

Стандартная библиотека C использует время Unix для всех функций даты и времени, а время Unix иногда называют time_t, именем типа данных , используемого для временных меток в C и C++ . Функции времени Unix в C определены как API системного времени в спецификации POSIX . [15] Стандартная библиотека C широко используется во всех современных настольных операционных системах, включая Microsoft Windows и Unix-подобные системы, такие как macOS и Linux , где она является стандартным интерфейсом программирования. [16] [17] [18]

iOS предоставляет API Swift, который по умолчанию использует эпоху 1 января 2001 года, но может также использоваться с временными метками Unix. [19] Android использует время Unix вместе с часовым поясом для своего API системного времени. [20]

Windows не использует время Unix для внутреннего хранения времени, но использует его в системных API, которые предоставляются в C++ и реализуют спецификацию стандартной библиотеки C. [16] Время Unix используется в формате PE для исполняемых файлов Windows. [21]

Время Unix обычно доступно в основных языках программирования и широко используется в программировании настольных, мобильных и веб-приложений. Java предоставляет объект Instant, который содержит временную метку Unix как в секундах, так и в наносекундах. [22] Python предоставляет библиотеку времени, которая использует время Unix. [23] JavaScript предоставляет библиотеку Date, которая предоставляет и хранит временные метки в миллисекундах с эпохи Unix и реализована во всех современных настольных и мобильных веб-браузерах , а также в серверных средах JavaScript , таких как Node.js. [24]

Файловые системы, разработанные для использования с операционными системами на базе Unix, как правило, используют время Unix. APFS , файловая система, используемая по умолчанию на всех устройствах Apple, и ext4 , которая широко используется на устройствах Linux и Android, используют время Unix в наносекундах для временных меток файлов. [25] [26] Несколько форматов архивных файлов могут хранить временные метки в формате времени Unix, включая RAR и tar . [27] [28] Время Unix также обычно используется для хранения временных меток в базах данных, включая MySQL и PostgreSQL . [29] [30]

Ограничения

Время Unix было разработано для кодирования календарных дат и времени в компактной форме, предназначенной для внутреннего использования компьютерами. Оно не предназначено для легкого чтения людьми или для хранения значений, зависящих от часового пояса. Оно также ограничено по умолчанию представлением времени в секундах, что делает его непригодным для использования, когда требуется более точное измерение времени, например, при измерении времени выполнения программ. [31]

Диапазон представляемых времен

Анимированное изображение переполнения 32-битного времени Unix, которое произойдет в 2038 году

Время Unix по своей конструкции не требует определенного размера для хранения, но большинство распространенных реализаций времени Unix используют знаковое целое число того же размера, что и размер слова базового оборудования. Поскольку большинство современных компьютеров являются 32- или 64-разрядными , а большое количество программ по-прежнему написано в режиме совместимости с 32-разрядной архитектурой, это означает, что многие программы, использующие время Unix, используют поля знаковых 32-разрядных целых чисел. Максимальное значение знакового 32-разрядного целого числа равно 2 31 − 1 , а минимальное значение равно −2 31 , что делает невозможным представление дат до 13 декабря 1901 года (в 20:45:52 UTC) или после 19 января 2038 года (в 03:14:07 UTC). Раннее отключение может оказать влияние на базы данных, в которых хранится историческая информация; В некоторых базах данных, где для временных меток используется 32-битное время Unix, может потребоваться хранить время в поле другой формы, например, в виде строки, для представления дат до 1901 года. Позднее отсечение известно как проблема 2038 года и может вызвать проблемы по мере приближения даты, поскольку даты после отсечки 2038 года будут возвращаться к началу представляемого диапазона в 1901 году. [31] : 60 

Ограничения диапазона дат не являются проблемой при 64-битном представлении времени Unix, поскольку эффективный диапазон дат, представляемых временем Unix, сохраненным в виде 64-битного целого числа со знаком, составляет более 584 миллиардов лет или 292 миллиарда лет в любом направлении от эпохи 1970 года. [31] : 60-61  [32]

Альтернативы

Время Unix — не единственный стандарт времени, отсчитывающий время от эпохи. В Windows этот FILETIMEтип хранит время как количество 100-наносекундных интервалов, прошедших с 0:00 GMT 1 января 1601 года. [33] Время эпохи Windows используется для хранения временных меток для файлов [34] и в таких протоколах, как Active Directory Time Service [35] и Server Message Block .

Сетевой протокол времени, используемый для координации времени между компьютерами, использует эпоху 1 января 1900 года, отсчитываемую беззнаковым 32-битным целым числом для секунд и другим беззнаковым 32-битным целым числом для дробных секунд, которые переходят каждые 2,32 секунды (примерно раз в 136 лет). [36]

Многие приложения и языки программирования предоставляют методы для хранения времени с явным указанием часового пояса. [37] Существует также ряд стандартов формата времени, которые могут читать как люди, так и компьютеры, например ISO 8601 .

Известные события в эпоху Unix

Энтузиасты Unix имеют историю проведения "time_t parties" (произносится как "time tea parties "), чтобы отпраздновать значимые значения числа времени Unix. [38] [39] Это прямой аналог празднования Нового года , которое происходит при смене года во многих календарях. По мере распространения использования времени Unix распространилась и практика празднования его вех. Обычно отмечаются значения времени, которые являются круглыми числами в десятичной системе счисления , следуя соглашению Unix о представлении time_tзначений в десятичной системе счисления. Среди некоторых групп также отмечаются круглые двоичные числа, например, +2 30 , которое произошло в 13:37:04 UTC в субботу, 10 января 2004 года. [ необходима цитата ]

События, которые они отмечают, обычно описываются как « N секунд с начала эпохи Unix», но это неточно; как обсуждалось выше, из-за обработки дополнительных секунд в Unix-времени количество секунд, прошедших с начала эпохи Unix, немного больше, чем число секунд Unix-времени для времени, наступившего позже эпохи.

В популярной культуре

Роман Вернора Винджа «Глубина в небе » описывает космическую торговую цивилизацию, существующую тысячи лет в будущем, которая все еще использует эпоху Unix. « Программист-археолог », ответственный за поиск и поддержание пригодного к использованию кода в зрелых компьютерных системах, сначала полагает, что эпоха относится ко времени, когда человек впервые ступил на Луну , но затем понимает, что это «нулевая секунда одной из первых компьютерных операционных систем человечества». [47]

Смотрите также

Примечания

  1. ^ Время Unix также известно как «время эпохи», « время POSIX », [2] «секунды с начала эпохи», [3] «отметка времени Unix» или «время эпохи UNIX». [4]
  2. ^ цитируется с обратной силой, поскольку ISO 8601 был опубликован в 1988 году.

Ссылки

  1. ^ ab Farhad, Manjoo (8 сентября 2001 г.). «Unix Tick Tocks to a Billion». Wired . ISSN  1059-1028. Архивировано из оригинала 11 сентября 2022 г. Получено 16 октября 2022 г.
  2. ^ "The Open Group Base Specifications Issue 7, Rationale: Base Definitions, section A.4 General Concepts". The Open Group . Архивировано из оригинала 15 ноября 2017 г. Получено 9 сентября 2019 г.
  3. ^ abc "The Open Group Base Specifications Issue 7, section 4.16 Seconds Since the Epoch". The Open Group . Архивировано из оригинала 22 декабря 2017 года . Получено 22 января 2017 года .
  4. ^ Мэтью, Нил; Стоунз, Ричард (2008). "Среда Linux". Начало программирования Linux . Индианаполис, Индиана, США: Wiley. стр. 148. ISBN 978-0-470-14762-7.
  5. ^ "Структура FILETIME (minwinbase.h)". Microsoft Docs . 2 апреля 2021 г.
  6. ^ Миллс, Дэвид Л. (12 мая 2012 г.). «Шкала времени NTP и високосные секунды». eecis.udel.edu . Архивировано из оригинала 15 мая 2012 г. . Получено 21 августа 2017 г. .
  7. ^ "Точное хронометрирование". Источники данных о часовом поясе и летнем времени . Архивировано из оригинала 16 октября 2017 г. Получено 30 мая 2022 г. Код и данные tz поддерживают високосные секунды через дополнительную "правильную" конфигурацию, в которой внутренние целочисленные часы time_t компьютера отсчитывают каждую секунду TAI, в отличие от конфигурации по умолчанию "posix", в которой внутренние часы игнорируют високосные секунды. Две конфигурации совпадают для временных меток, начинающихся с 1972-01-01 00:00:00 UTC (time_t 63 072 000), и расходятся для временных меток, начинающихся с time_t 78 796 800, что соответствует первой високосной секунде 1972-06-30 23:59:60 UTC в «правильной» конфигурации и 1972-07-01 00:00:00 UTC в конфигурации «posix».
  8. ^ ab "Time Scales". Network Time Protocol Wiki . 24 июля 2019 г. Архивировано из оригинала 12 января 2020 г. Получено 12 января 2020 г.
  9. ^ Маркус Кун. "Modernized API for ISO C". www.cl.cam.ac.uk . Архивировано из оригинала 26 сентября 2020 г. . Получено 31 августа 2020 г. .
  10. ^ "timespec". Страницы руководства NetBSD . 12 апреля 2011 г. Архивировано из оригинала 10 августа 2019 г. Получено 5 июля 2019 г.
  11. ^ "time.h(0P)". Страница руководства Linux . Архивировано из оригинала 27 июня 2019 г. Получено 5 июля 2019 г.
  12. ^ Маккарти, ДД ; Зайдельман, П.К. (2009). ВРЕМЯ — От вращения Земли до атомной физики . Вайнхайм: Wiley–VCH Verlag GmbH & Co. KGaA. стр. 232. ISBN 978-3-527-40780-4.
  13. ↑ Unix Programmer's Manual (PDF) (1-е изд.). 3 ноября 1971 г. Архивировано (PDF) из оригинала 5 марта 2022 г. Получено 28 марта 2012 г. time возвращает время с 00:00:00 1 января 1971 г., измеренное в шестидесятых долях секунды.
  14. ^ Unix Programmer's Manual (PDF) (3-е изд.). 15 марта 1972 г. Архивировано (PDF) из оригинала 12 февраля 2023 г. Получено 11 февраля 2023 г. time возвращает время с 00:00:00, 1 января 1972 г., измеренное в шестидесятых долях секунды... Время хранится в 32 битах. Это гарантирует кризис каждые 2,26 года.
  15. ^ "The Open Group Technical Standard Base Specifications Issue 7 (2018 edition)". IEEE и The Open Group. Архивировано из оригинала 1 мая 2023 года . Получено 1 мая 2023 года .
  16. ^ ab "time, _time32, _time64". learn.microsoft.net . Корпорация Microsoft. 13 февраля 2023 г. Архивировано из оригинала 1 мая 2023 г. Получено 1 мая 2023 г.
  17. ^ "Библиотека GNU C (glibc)". GNU Operating Sisyem . Free Software Foundation. Архивировано из оригинала 22 апреля 2016 г. Получено 1 мая 2023 г. Проект библиотеки GNU C предоставляет основные библиотеки для системы GNU и систем GNU/Linux, а также многих других систем, использующих Linux в качестве ядра.
  18. ^ "Mac OS X Manual Page for localtime(3)". Архив документации Apple . Apple Inc. Архивировано из оригинала 22 июля 2022 г. Получено 1 мая 2023 г.
  19. ^ "NSDate". Документация разработчиков Apple . Apple Inc. Архивировано из оригинала 1 мая 2023 г. Получено 1 мая 2023 г.
  20. ^ "Time Overview". Android Open Source Project . Google LLC. Архивировано из оригинала 1 мая 2023 г. Получено 1 мая 2023 г.
  21. ^ "Формат PE - приложения Win32". learn.microsoft.com . Корпорация Microsoft. 24 марта 2023 г. Архивировано из оригинала 29 апреля 2023 г. Получено 1 мая 2023 г.
  22. ^ "Instant (Java Platform SE 8)". docs.oracle.com . Oracle. Архивировано из оригинала 25 ноября 2016 г. Получено 1 мая 2023 г.
  23. ^ "time — Time access and conversions", документация Python , заархивировано из оригинала 22 июля 2022 г. , извлечено 25 июля 2022 г.
  24. ^ "Дата - JavaScript | MDN". developer.mozilla.org . Mozilla. Архивировано из оригинала 21 июля 2021 г. Получено 1 мая 2023 г.
  25. ^ Справочник файловой системы Apple (PDF) , стр. 57, заархивировано (PDF) из оригинала 5 ноября 2022 г. , извлечено 19 октября 2022 г. , Эта временная метка представлена ​​как количество наносекунд с 1 января 1970 года в 0:00 UTC, без учета дополнительных секунд.
  26. ^ "Data Structures and Algorithms". Документация ядра Linux . Linux Kernel Organization, Inc. Архивировано из оригинала 1 мая 2023 г. Получено 1 мая 2023 г.
  27. ^ "Формат архива RAR 5.0". www.rarlab.com . win.rar GmbH. Архивировано из оригинала 1 мая 2023 г. Получено 1 мая 2023 г. Время хранится в формате Unix time_t, если этот флаг [sic] установлен, и в формате Windows FILETIME в противном случае
  28. ^ "Tape Archive (tar) File Format Family". www.loc.gov . Библиотека Конгресса. 7 января 2021 г. Архивировано из оригинала 1 мая 2023 г. Получено 1 мая 2023 г.
  29. ^ «Функции даты и времени», MySQL 8.0 Reference Manual , архивировано из оригинала 19 октября 2022 г. , извлечено 19 октября 2022 г.
  30. ^ "8.5. Типы даты/времени". Документация PostgreSQL . Группа глобальной разработки PostgreSQL. 9 февраля 2023 г. Архивировано из оригинала 1 мая 2023 г. Получено 1 мая 2023 г.
  31. ^ abc Rochkind, Mark (2004). Advanced UNIX Programming (2-е изд.). Addison-Wesley. стр. 56–63. ISBN 978-0-13-141154-8.
  32. ^ Саксена, Ашутош; Рават, Санджай. "IDRBT Working Paper No. 9" (PDF) . Архивировано из оригинала (PDF) 13 мая 2012 г.
  33. ^ "FILETIME (minwinbase.h) - Win32 apps". Microsoft Learn . Microsoft. 2 апреля 2021 г. Архивировано из оригинала 10 марта 2023 г. Получено 9 марта 2023 г.
  34. ^ "File Times - Win32 apps". Microsoft Learn . Microsoft. 7 января 2021 г. Архивировано из оригинала 8 марта 2023 г. Получено 9 марта 2023 г.
  35. ^ "Как преобразовать атрибуты даты/времени в Active Directory в стандартный формат времени". Microsoft Learn . Microsoft. Архивировано из оригинала 20 октября 2022 г. Получено 20 октября 2022 г.
  36. ^ W. Richard Stevens; Bill Fenner; Andrew M. Rudoff (2004). Сетевое программирование UNIX. Addison-Wesley Professional. стр. 582–. ISBN 978-0-13-141155-5. Архивировано из оригинала 30 марта 2019 . Получено 16 октября 2016 .
  37. ^ "datetime — Базовые типы даты и времени". Справочник по стандартной библиотеке Python . Python Software Foundation. Архивировано из оригинала 19 октября 2022 г. Получено 20 октября 2022 г. Атрибуты: год, месяц, день, час, минута, секунда, микросекунда и tzinfo.
  38. ^ ab Tweney, Dylan (12 февраля 2009 г.). «Unix Lovers to Party Like It's 1234567890». Wired . Архивировано из оригинала 29 марта 2014 г. Получено 12 марта 2017 г.
  39. ^ "Slashdot | date +%s Turning 1111111111". 17 марта 2005 г. Архивировано из оригинала 12 января 2020 г. Получено 12 января 2020 г.[ ненадежный источник? ]
  40. ^ "Факты и мелочи о Unix time – Unix Time . Информация". Архивировано из оригинала 27 октября 2017 г.
  41. ^ "UNIX приближается к зрелому возрасту в один миллиард". Electromagnetic.net. Архивировано из оригинала 13 апреля 2013 года . Получено 6 декабря 2012 года .
  42. ^ Neumann, Peter G. (15 октября 2001 г.). "The RISKS Digest, Volume 21 Issue 69". The Risks Digest . 21 (69). Архивировано из оригинала 22 октября 2015 г. Получено 6 декабря 2012 г.
  43. ^ "Технические проблемы". linuxmafia.com . Архивировано из оригинала 11 октября 2012 . Получено 21 августа 2017 .
  44. ^ nixCraft. "Юмор: В пятницу 13 февраля 2009 года время Unix будет 1234567890". Cyberciti.biz . Получено 5 июля 2023 г. .
  45. ^ "Google 1234567890 Logo". Google Inc. Архивировано из оригинала 11 января 2013 года . Получено 28 января 2013 года .
  46. ^ Ахмед, Мурад (13 февраля 2009 г.). «В третий раз время Unix будет 1234567890». The Times . Архивировано из оригинала 14 ноября 2016 г. Получено 12 января 2020 г.
  47. ^ Mashey, John R. (27 декабря 2004 г.). «Языки, уровни, библиотеки и долголетие». Очередь . 2 (9): 32–38. doi : 10.1145/1039511.1039532 . S2CID  28911378.

Внешние ссылки

Викиверситет содержит обучающие ресурсы по конвертеру JavaScript/Epoch time