Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Информацию о функции времени в Википедии или #time см. В разделе Справка: функция времени .
Текущее время Unix
1613990609 (обновление)
(2021-02-22T10: 43: 29 + 00: 00)
Прошло время Unix 1 000 000 000 секунд 2001-09-09T01: 46: 40Z. Он был отмечен в Копенгагене, Дания, на вечеринке, организованной DKUUG (в 03:46:40 по местному времени).

Unix время (также известное как Epoch время , POSIX время , [1] секунды с началом эпохи , [2] или UNIX , эпоха время [3] ) представляет собой систему для описания точки во время . Это количество секунд , прошедших с эпохи Unix , минус дополнительные секунды ; эпоха Unix - 00:00:00 UTC 1 января 1970 г. (произвольная дата); дополнительные секунды игнорируются [4], при этом дополнительная секунда имеет то же время Unix, что и секунда перед ней, и каждый день обрабатывается так, как если бы он содержал точно86 400 секунд. [2] Из-за такой обработки время Unix не является истинным представлением UTC.

Время Unix широко используется в операционных системах и форматах файлов . В Unix-подобных операционных системах dateэто команда, которая печатает или устанавливает текущее время; по умолчанию он печатает или устанавливает время в системном часовом поясе , но с -uфлагом он печатает или устанавливает время в формате UTC, а с TZ переменной среды, установленной для ссылки на конкретный часовой пояс, печатает или устанавливает время в этом часовой пояс. [5]

Определение [ править ]

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

Как и в стандарте UTC, в этой статье дни помечаются по григорианскому календарю , а время каждого дня подсчитывается в часах, минутах и ​​секундах. Некоторые из примеров также показывают Международное атомное время (TAI), другую временную схему, которая использует те же секунды и отображается в том же формате, что и UTC, но в которой каждый день точно соответствует86 400 секунд, постепенно теряя синхронизацию с вращением Земли со скоростью примерно одну секунду в год.

Кодирование времени в виде числа [ править ]

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

Unix эпохи время 00:00:00  UTC 1 января 1970 года [2] Существует проблема с этим определением, в том , что не UTC не существовало в его нынешнем виде до 1972 года; этот вопрос обсуждается ниже. Для краткости в оставшейся части этого раздела используется формат даты и времени ISO 8601 , в котором эпоха Unix - 1970-01-01T00: 00: 00Z.

Временное число Unix равно нулю в эпоху Unix и увеличивается ровно на 86 400 в сутки с эпохи. Таким образом, 2004-09-16T00: 00: 00Z,12 677 дней после эпохи, представлено числом времени Unix12 677 ×86 400 =1 095 292 800 . Это также может быть продлено назад от эпохи, используя отрицательные числа; таким образом, 1957-10-04T00: 00: 00Z,4472 дня до эпохи, представлено числом времени Unix-4472 ×86 400 =−386 380 800 . Это также применимо в течение нескольких дней; число времени в любое заданное время дня - это количество секунд, прошедших с полуночи, начиная с этого дня, добавленное к числу времени этой полуночи.

Поскольку время Unix основано на эпохе, и из-за распространенного заблуждения, что эпоха Unix является единственной эпохой (часто называемой « эпохой » [2] ), время Unix иногда называют временем эпохи . [7] [8] [9]

Високосные секунды [ править ]

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

Время Unix до полуночи 17 сентября 2004 г. (без дополнительной секунды)
TAI (17 сентября 2004 г.)UTC (16-17 сентября 2004 г.)Время Unix
2004-09-17T00: 00: 30.752004-09-16T23: 59: 58.751 095 379 198 0,75
2004-09-17T00: 00: 31.002004-09-16T23: 59: 59.001 095 379 199 0,00
2004-09-17T00: 00: 31.252004-09-16T23: 59: 59.251 095 379 199 0,25
2004-09-17T00: 00: 31.502004-09-16T23: 59: 59.501 095 379 199 0,50
2004-09-17T00: 00: 31.752004-09-16T23: 59: 59.751 095 379 199 0,75
2004-09-17T00: 00: 32.002004-09-17T00: 00: 00.001 095 379 200 .00
2004-09-17T00: 00: 32.252004-09-17T00: 00: 00.251 095 379 200 0,25
2004-09-17T00: 00: 32.502004-09-17T00: 00: 00.501 095 379 200 0,50
2004-09-17T00: 00: 32.752004-09-17T00: 00: 00.751 095 379 200 0,75
2004-09-17T00: 00: 33.002004-09-17T00: 00: 01.001 095 379 201 .00
2004-09-17T00: 00: 33.252004-09-17T00: 00: 01.251 095 379 201 0,25

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

Время Unix через полночь до 1 января 1999 г. (положительная дополнительная секунда)
TAI (1 января 1999 г.)UTC (31 декабря 1998 г. - 1 января 1999 г.)Время Unix
1999-01-01T00: 00: 29.751998-12-31T23: 59: 58.75915 148 798 0,75
1999-01-01T00: 00: 30.001998-12-31T23: 59: 59.00915 148 799 +0,00
1999-01-01T00: 00: 30.251998-12-31T23: 59: 59.25915 148 799 +0,25
1999-01-01T00: 00: 30.501998-12-31T23: 59: 59.50915 148 799 0,50
1999-01-01T00: 00: 30.751998-12-31T23: 59: 59.75915 148 799 0,75
1999-01-01T00: 00: 31.001998-12-31T23: 59: 60.00915 148 800 .00
1999-01-01T00: 00: 31.251998-12-31T23: 59: 60.25915 148 800 .25
1999-01-01T00: 00: 31.501998-12-31T23: 59: 60.50915 148 800 0,50
1999-01-01T00: 00: 31.751998-12-31T23: 59: 60.75915 148 800 0,75
1999-01-01T00: 00: 32.001999-01-01T00: 00: 00.00915 148 800 .00
1999-01-01T00: 00: 32.251999-01-01T00: 00: 00.25915 148 800 .25
1999-01-01T00: 00: 32.501999-01-01T00: 00: 00.50915 148 800 0,50
1999-01-01T00: 00: 32.751999-01-01T00: 00: 00.75915 148 800 0,75
1999-01-01T00: 00: 33.001999-01-01T00: 00: 01.00915 148 801 .00
1999-01-01T00: 00: 33.251999-01-01T00: 00: 01.25915 148 801 0,25

Числа времени Unix повторяются в секундах сразу после положительной дополнительной секунды. Число времени Unix1 483 142 400 , таким образом, неоднозначен: он может относиться либо к началу дополнительной секунды (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 . Частное - это количество дней с начала эпохи, а модуль - это количество секунд с полуночи по всемирному координированному времени в этот день. Если задано число времени Unix, которое неоднозначно из-за положительной дополнительной секунды, этот алгоритм интерпретирует его как время сразу после полуночи. Он никогда не генерирует время, равное секунде координации. Если задано число времени Unix, которое недействительно из-за отрицательной дополнительной секунды, оно генерирует одинаково недействительное время UTC. Если эти условия значительны, для их обнаружения необходимо обратиться к таблице дополнительных секунд.

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

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

Несинхронные часы Unix в стиле Миллса
через полночь 1 января 1999 г. (положительная дополнительная секунда)
TAI (1 января 1999 г.)UTC (31 декабря 1998 г. - 1 января 1999 г.)СостояниеЧасы Unix
1999-01-01T00: 00: 29.751998-12-31T23: 59: 58.75TIME_INS915 148 798 0,75
1999-01-01T00: 00: 30.001998-12-31T23: 59: 59.00TIME_INS915 148 799 +0,00
1999-01-01T00: 00: 30.251998-12-31T23: 59: 59.25TIME_INS915 148 799 +0,25
1999-01-01T00: 00: 30.501998-12-31T23: 59: 59.50TIME_INS915 148 799 0,50
1999-01-01T00: 00: 30.751998-12-31T23: 59: 59.75TIME_INS915 148 799 0,75
1999-01-01T00: 00: 31.001998-12-31T23: 59: 60.00TIME_INS915 148 800 .00
1999-01-01T00: 00: 31.251998-12-31T23: 59: 60.25TIME_OOP915 148 799 +0,25
1999-01-01T00: 00: 31.501998-12-31T23: 59: 60.50TIME_OOP915 148 799 0,50
1999-01-01T00: 00: 31.751998-12-31T23: 59: 60.75TIME_OOP915 148 799 0,75
1999-01-01T00: 00: 32.001999-01-01T00: 00: 00.00TIME_OOP915 148 800 .00
1999-01-01T00: 00: 32.251999-01-01T00: 00: 00.25ВРЕМЯ ЖДЕТ915 148 800 .25
1999-01-01T00: 00: 32.501999-01-01T00: 00: 00.50ВРЕМЯ ЖДЕТ915 148 800 0,50
1999-01-01T00: 00: 32.751999-01-01T00: 00: 00.75ВРЕМЯ ЖДЕТ915 148 800 0,75
1999-01-01T00: 00: 33.001999-01-01T00: 00: 01.00ВРЕМЯ ЖДЕТ915 148 801 .00
1999-01-01T00: 00: 33.251999-01-01T00: 00: 01.25ВРЕМЯ ЖДЕТ915 148 801 0,25

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

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

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

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

Вариант на основе TAI [ править ]

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

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

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

Представление числа [ править ]

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

Тип time_tданных Unix , представляющий момент времени, на многих платформах представляет собой целое число со знаком , традиционно состоящее из 32 бит (но см. Ниже), непосредственно кодирующее временное число Unix, как описано в предыдущем разделе. 32 бита означает, что в общей сложности он охватывает около 136 лет. Минимальная представимая дата - пятница 13 декабря 1901 года, а максимальная представимая дата - вторник 19 января 2038 года. Через секунду после 03:14:07 UTC 2038-01-19 это представление переполнится . Эту веху ожидают со смесью веселья и страха - см. Проблему 2038 года .  

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

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

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

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

Основание 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 года рассматривается возможность прекращения использования дополнительных секунд в гражданском времени. [15] Вероятным средством выполнения этого изменения является определение новой шкалы времени, называемой международным временем , которая первоначально соответствует UTC, но после этого не имеет дополнительных секунд, таким образом оставаясь с постоянным смещением от TAI. Если это произойдет, вполне вероятно, что время Unix будет перспективно определено в терминах этой новой шкалы времени, а не в формате UTC. Неуверенность в том, произойдет ли это, делает предполагаемое время Unix не менее предсказуемым, чем оно есть сейчас: если бы UTC просто не имело дополнительных дополнительных секунд, результат был бы таким же.

История [ править ]

В самых ранних версиях Unix time было 32-битное целое число, увеличивающееся со скоростью 60  Гц , которая была частотой системных часов на оборудовании ранних систем Unix. В результате значение 60 Гц все еще появляется в некоторых интерфейсах программного обеспечения. Эпоха также отличалась от нынешнего значения. В первом издании Unix Programmer's Manual от 3 ноября 1971 года время Unix определяется как «время с 00:00:00 1 января 1971 года, измеренное в шестидесятых долях секунды». [16]

В Руководстве пользователя также отмечается, что «хронологически мыслящий пользователь заметит, что 2 ** 32 шестидесятых секунды - это всего лишь около 2,5 лет». Из-за этого ограниченного диапазона эпоха переопределялась более одного раза, прежде чем частота была изменена на 1 Гц, а эпоха была установлена ​​на ее текущее значение на 1 января 1970 г., 00:00:00 UTC. Это дало диапазон около 136 лет, половина из которых была до 1970 года, а половина - после.

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

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

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

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

Известные события во времена Unix [ править ]

Энтузиасты Unix имеют историю проведения «time_t партии» (произносится как «время чаепития ») , чтобы отметить существенные значения числа времени Unix. [17] [18] Это прямо аналогично празднованию нового года, которое происходит при смене года во многих календарях. По мере того, как использование Unix расширяется, растет и практика празднования его вех. Обычно отмечаются значения времени, представляющие собой круглые числа в десятичной системе счисления , в соответствии с соглашением Unix о просмотре time_tзначений в десятичном формате . Среди некоторых групп также отмечаются круглые двоичные числа, например, +2 30, которое произошло в 13:37:04 UTC в субботу, 10 января 2004 г. [цитата необходима ]

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

  • В среду, 17 октября 1973 г., в 18:36:57 по Гринвичу дата в формате ISO 8601 [a] (1973-10-17) впервые появилась внутри цифр времени Unix (119731017).
  • В 01:46:40 UTC в воскресенье, 9 сентября 2001 г., Unix billennium (номер времени Unix 1 000 000 000 ). [19] Название Billennium является контаминация из миллиардов и тысячелетия . [20] [21] Некоторые программы, которые сохраняли метки времени с использованием текстового представления, сталкивались с ошибками сортировки, например, время сортировки текста после оборота, начиная с 1 цифры, ошибочно отсортировано до более раннего времени, начиная с 9 цифр. Затронутые программы включали популярный читатель Usenet KNode и клиент электронной почты KMail , входящий в состав KDE.среда рабочего стола. Такие ошибки обычно носили косметический характер и быстро исправлялись, как только проблемы становились очевидными. Проблема также затронула многие фильтры Filtrix формата документа, поставляемые с версиями WordPerfect для Linux ; сообществом пользователей был создан патч для решения этой проблемы, поскольку Corel больше не продавал и не поддерживал эту версию программы. [22]
  • В 23:31:30 UTC в пятницу, 13 февраля 2009 г., десятичное представление времени Unix достигло1 234 567 890 секунд. [23] Google отпраздновал это дудлом Google . [24] Вечеринки и другие торжества проводились по всему миру среди различных технических субкультур, чтобы отпраздновать1 234 567 890- я секунда. [17] [25]
  • В среду, 18 мая 2033 года в 03:33:20 UTC, значение времени Unix будет равно 2 000 000 000 секунд.
  • В 06:28:16 UTC в четверг, 7 февраля 2036 г., протокол сетевого времени перейдет к следующей эпохе, поскольку 32-битное значение отметки времени, используемое в NTP (без знака, но основанное на 1 января 1900 г.), переполнится. Эта дата близка к следующей дате, потому что 136-летний диапазон 32-битного целого числа секунд почти в два раза больше 70-летнего смещения между двумя эпохами.
  • В 03:14:08 UTC во вторник, 19 января 2038 г., 32-разрядные версии метки времени Unix перестанут работать, так как она переполнит наибольшее значение, которое может содержаться в 32-разрядном числе со знаком ( 7FFFFFFF 16 или2 147 483 647 ). До этого момента программное обеспечение, использующее 32-битные метки времени, должно будет принять новое соглашение для меток времени [26], а форматы файлов, использующие 32-битные метки времени, необходимо будет изменить для поддержки больших меток времени или другой эпохи. Если без изменений, то следующий второй будет неправильно истолковано как 20:45:52 пятницу 13 декабря 1901 UTC . Это называется проблемой 2038 года .
  • В 05:20:00 UTC в субботу, 24 января 2065 г., значение времени Unix будет равно 3 000 000 000 секунд.
  • В 06:28:15 UTC в воскресенье, 7 февраля 2106 года, время Unix достигнет FFFFFFFF 16 или4 294 967 295 секунд, что для систем, хранящих время на 32-битных целых числах без знака, является максимально достижимым. Для некоторых из этих систем следующая секунда будет неправильно интерпретирована как 00:00:00 в четверг, 1 января 1970 г., UTC . В других системах может возникнуть ошибка переполнения с непредсказуемыми результатами. [ необходима цитата ]
  • В воскресенье, 4 декабря, в 15:30:08 UTC. 292 277 026 596 , [27] [28] 64-битные версии метки времени Unix перестают работать, поскольку она переполняет наибольшее значение, которое может содержаться в 64-битном числе со знаком. Это почти в 22 раза больше текущего возраста Вселенной , что составляет1,37 × 10 10 лет (13,7 млрд).

В литературе и календарях [ править ]

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

См. Также [ править ]

  • Эпоха (вычисления)
  • Системное время

Примечания [ править ]

  1. ^ цитируется задним числом с момента публикации ISO 8601 в 1988 г.

Ссылки [ править ]

  1. ^ «Базовые спецификации Open Group, выпуск 7, Обоснование: Базовые определения, раздел A.4 Общие концепции» . Открытая группа . Проверено 9 сентября 2019 .
  2. ^ a b c d «Базовые спецификации открытой группы, выпуск 7, раздел 4.16 секунд с начала эпохи» . Открытая группа . Проверено 22 января 2017 года .
  3. ^ Мэтью, Нил; Камни, Ричард (2008). «Среда Linux». Начало программирования под Linux . Индианаполис, Индиана, США: Wiley. п. 148. ISBN 978-0-470-14762-7.
  4. ^ «Базовые спецификации открытой группы, выпуск 7, обоснование, раздел 4.16 секунд с эпохи» . OpenGroup . Проверено 22 января 2017 года .
  5. ^ date  - Справочник по командам и служебным программам, спецификация Single UNIX , выпуск 7 от The Open Group
  6. ^ «Конвертер эпохи - Конвертер отметок времени Unix» . Конвертер эпохи . Проверено 12 января 2020 года .
  7. ^ «Обработка меток времени с использованием формата даты в ярлыках» . Apple , Inc . Проверено 19 июня 2019 .
  8. ^ «Формат даты RAW в отчетах, экспортированных в CSV» . Международная корпорация бизнес-машин (IBM) . Проверено 19 июня 2019 .
  9. ^ «TIMESTAMP BY (Azure Stream Analytics)» . Корпорация Microsoft . Проверено 19 июня 2019 .
  10. ↑ Миллс, Дэвид Л. (12 мая 2012 г.). «Шкала времени NTP и дополнительные секунды» . eecis.udel.edu . Проверено 21 августа 2017 года .
  11. ^ «Шкалы времени» . Wiki протокола сетевого времени . 24 июля 2019 . Проверено 12 января 2020 года .
  12. ^ Маркус Кун. «Модернизированный API для ISO C» . www.cl.cam.ac.uk .
  13. ^ "время" . Страницы руководства NetBSD . 12 апреля 2011 . Дата обращения 5 июля 2019 .
  14. ^ "time.h (0P)" . Страница руководства Linux . Дата обращения 5 июля 2019 .
  15. ^ Маккарти, DD ; Зайдельманн, ПК (2009). ВРЕМЯ - от вращения Земли к атомной физике . Вайнхайм: Wiley – VCH Verlag GmbH & Co. KGaA. п. 232. ISBN. 978-3-527-40780-4.
  16. ^ Руководство программиста Unix (PDF) (1-е изд.). 3 ноября 1971 . Проверено 28 марта 2012 года . time возвращает время с 00:00:00 1 января 1971 г., измеренное в шестидесятых долях секунды.
  17. ^ a b Твини, Дилан (12 февраля 2009 г.). «Unix Lovers to Party Like It 1234567890» . Проводной .
  18. ^ "Slashdot | date +% s Turning 1111111111" . 17 марта 2005 г.[ ненадежный источник? ]
  19. ^ "Факты и мелочи времени Unix - Время Unix. Информация" . Архивировано из оригинального 27 -го октября 2017 года.
  20. ^ «UNIX приближается к зрелой старости в один миллиард» . Электромагнитный.net. Архивировано из оригинального 13 апреля 2013 года . Проверено 6 декабря 2012 года .
  21. ^ "Дайджест рисков Том 21: Выпуск 69" . Catless.ncl.ac.uk . Проверено 6 декабря 2012 года .
  22. ^ «Технические проблемы» . linuxmafia.com . Проверено 21 августа 2017 года .
  23. ^ nixCraft. «Юмор: 13 февраля, пятница, 13, 2009 Unix-время будет 1234567890» . Cyberciti.biz . Проверено 6 декабря 2012 года .
  24. ^ "Логотип Google 1234567890" . Google Inc . Проверено 28 января 2013 года .
  25. ↑ Ахмед, Мурад (13 февраля 2009 г.). «При третьем ударе время Unix будет 1234567890» . The Times .
  26. ^ "Unix Time Stamp.com" . UnixTimeStamp.com . Проверено 12 января 2020 года .
  27. ↑ Spinellis, Diomidis (7 апреля 2006 г.). Качество кода: перспектива открытого исходного кода . ISBN 9780321166074.
  28. ^ Рабочий документ IDRBT № 9 Y2K38 - Ашутош Саксена и Санджай Рават
  29. ^ Mashey, Джон Р. (27 декабря 2004). «Языки, уровни, библиотеки и долголетие» . Очередь . 2 (9): 32–38. DOI : 10.1145 / 1039511.1039532 . S2CID 28911378 . 

Внешние ссылки [ править ]

  • Руководство программиста Unix, первое издание
  • Личный счет решений POSIX по Лэндон Curt Noll
  • Клеветт, Джеймс. 2 147 483 647 - Конец времен [Unix] .
  • хроно-совместимые низкоуровневые алгоритмы даты - алгоритмы для преобразования между григорианской и юлианской датами и количеством дней с начала времени Unix