Время Unix - Unix time

Чтобы узнать о функции времени в Википедии или #time, см. Справка: функция времени.

Текущее время Unix
1607288941 (Обновить)
(2020-12-06T21: 09: 01 + 00: 00)

Прошло время Unix 1000000000 секунд 2001-09-09T01: 46: 40Z. Он был отмечен в Копенгагене, Дания, на вечеринке, организованной ДКУУГ (в 03:46:40 по местному времени).

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

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

Определение

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

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

Кодирование времени в виде числа

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

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

Временное число Unix равно нулю в эпоху Unix и увеличивается ровно на 86400 в сутки с эпохи. Таким образом, 2004-09-16T00: 00: 00Z, 12677 дней после эпохи, представлен числом времени Unix 12677 × 86400 = 1095292800. Это также может быть продлено назад от эпохи, используя отрицательные числа; таким образом, 1957-10-04T00: 00: 00Z, 4472 дней до эпохи, представлен числом времени Unix −4472 × 86400 = −386380800. Это также применимо в течение нескольких дней; число времени в любое заданное время дня - это количество секунд, прошедших с полуночи, начиная с этого дня, добавленное к числу времени этой полуночи.

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

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

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

Время Unix до полуночи 17 сентября 2004 г. (без дополнительной секунды)

TAI (17 сентября 2004 г.)	UTC (16-17 сентября 2004 г.)	Время Unix
2004-09-17T00: 00: 30.75	2004-09-16T23: 59: 58.75	1095379198.75
2004-09-17T00: 00: 31.00	2004-09-16T23: 59: 59.00	1095379199.00
2004-09-17T00: 00: 31.25	2004-09-16T23: 59: 59.25	1095379199.25
2004-09-17T00: 00: 31.50	2004-09-16T23: 59: 59.50	1095379199.50
2004-09-17T00: 00: 31.75	2004-09-16T23: 59: 59.75	1095379199.75
2004-09-17T00: 00: 32.00	2004-09-17T00: 00: 00.00	1095379200.00
2004-09-17T00: 00: 32.25	2004-09-17T00: 00: 00.25	1095379200.25
2004-09-17T00: 00: 32.50	2004-09-17T00: 00: 00.50	1095379200.50
2004-09-17T00: 00: 32.75	2004-09-17T00: 00: 00.75	1095379200.75
2004-09-17T00: 00: 33.00	2004-09-17T00: 00: 01.00	1095379201.00
2004-09-17T00: 00: 33.25	2004-09-17T00: 00: 01.25	1095379201.25

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

Время Unix через полночь до 1 января 1999 г. (положительная дополнительная секунда)

TAI (1 января 1999 г.)	UTC (31 декабря 1998 г. - 1 января 1999 г.)	Время Unix
1999-01-01T00: 00: 29.75	1998-12-31T23: 59: 58.75	915148798.75
1999-01-01T00: 00: 30.00	1998-12-31T23: 59: 59.00	915148799.00
1999-01-01T00: 00: 30.25	1998-12-31T23: 59: 59.25	915148799.25
1999-01-01T00: 00: 30.50	1998-12-31T23: 59: 59.50	915148799.50
1999-01-01T00: 00: 30.75	1998-12-31T23: 59: 59.75	915148799.75
1999-01-01T00: 00: 31.00	1998-12-31T23: 59: 60.00	915148800.00
1999-01-01T00: 00: 31.25	1998-12-31T23: 59: 60.25	915148800.25
1999-01-01T00: 00: 31.50	1998-12-31T23: 59: 60.50	915148800.50
1999-01-01T00: 00: 31.75	1998-12-31T23: 59: 60.75	915148800.75
1999-01-01T00: 00: 32.00	1999-01-01T00: 00: 00.00	915148800.00
1999-01-01T00: 00: 32.25	1999-01-01T00: 00: 00.25	915148800.25
1999-01-01T00: 00: 32.50	1999-01-01T00: 00: 00.50	915148800.50
1999-01-01T00: 00: 32.75	1999-01-01T00: 00: 00.75	915148800.75
1999-01-01T00: 00: 33.00	1999-01-01T00: 00: 01.00	915148801.00
1999-01-01T00: 00: 33.25	1999-01-01T00: 00: 01.25	915148801.25

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

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

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

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

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

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

Несинхронные часы Unix в стиле Миллса
через полночь 1 января 1999 г. (положительная дополнительная секунда)

TAI (1 января 1999 г.)	UTC (31 декабря 1998 г. - 1 января 1999 г.)	Состояние	Часы Unix
1999-01-01T00: 00: 29.75	1998-12-31T23: 59: 58.75	TIME_INS	915148798.75
1999-01-01T00: 00: 30.00	1998-12-31T23: 59: 59.00	TIME_INS	915148799.00
1999-01-01T00: 00: 30.25	1998-12-31T23: 59: 59.25	TIME_INS	915148799.25
1999-01-01T00: 00: 30.50	1998-12-31T23: 59: 59.50	TIME_INS	915148799.50
1999-01-01T00: 00: 30.75	1998-12-31T23: 59: 59.75	TIME_INS	915148799.75
1999-01-01T00: 00: 31.00	1998-12-31T23: 59: 60.00	TIME_INS	915148800.00
1999-01-01T00: 00: 31.25	1998-12-31T23: 59: 60.25	TIME_OOP	915148799.25
1999-01-01T00: 00: 31.50	1998-12-31T23: 59: 60.50	TIME_OOP	915148799.50
1999-01-01T00: 00: 31.75	1998-12-31T23: 59: 60.75	TIME_OOP	915148799.75
1999-01-01T00: 00: 32.00	1999-01-01T00: 00: 00.00	TIME_OOP	915148800.00
1999-01-01T00: 00: 32.25	1999-01-01T00: 00: 00.25	ВРЕМЯ ЖДЕТ	915148800.25
1999-01-01T00: 00: 32.50	1999-01-01T00: 00: 00.50	ВРЕМЯ ЖДЕТ	915148800.50
1999-01-01T00: 00: 32.75	1999-01-01T00: 00: 00.75	ВРЕМЯ ЖДЕТ	915148800.75
1999-01-01T00: 00: 33.00	1999-01-01T00: 00: 01.00	ВРЕМЯ ЖДЕТ	915148801.00
1999-01-01T00: 00: 33.25	1999-01-01T00: 00: 01.25	ВРЕМЯ ЖДЕТ	915148801.25

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

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

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

Логика декодирования, необходимая для работы с этим стилем часов Unix, также могла бы правильно декодировать гипотетические POSIX-совместимые часы с использованием того же интерфейса. Этого можно добиться, указав TIME_INS состояние в течение всей вставленной секунды координации, затем указывает ВРЕМЯ ЖДЕТ в течение всей следующей секунды, повторяя отсчет секунд. Это требует синхронной обработки секунды координации. Это, вероятно, лучший способ выразить время в формате 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] А tai_clock однако существует в C ++ 20.

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

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

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

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

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

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

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

Основание UTC

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

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

Значение значений времени Unix ниже [phone] (т.е. до 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³⁰ что произошло в 13:37:04 UTC в субботу, 10 января 2004 г.^{[нужна цитата ]}

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

• В среду, 17 октября 1973 г., в 18:36:57 UTC дата первого появления в ISO 8601 формат^[а] (1973-10-17) в разрядах Unix времени (119731017).
• В 01:46:40 UTC в воскресенье, 9 сентября 2001 г., Unix billennium (номер времени Unix 1000000000) праздновали.^[19] Название тысячелетие это чемодан из миллиард и тысячелетие.^[20][21] Некоторые программы, которые сохраняли временные метки с использованием текстового представления, сталкивались с ошибками сортировки, например, при сортировке текста по времени после оборота, начиная с 1 цифра, ошибочно отсортированная до более раннего времени, начиная с 9 цифра. Затронутые программы включают популярные Usenet читатель KNode и электронное письмо клиент KMail, часть KDE окружение рабочего стола. Такие ошибки обычно носили косметический характер и быстро исправлялись, как только проблемы становились очевидными. Проблема коснулась и многих Filtrix фильтры формата документа, поставляемые с Linux версии WordPerfect; сообществом пользователей был создан патч для решения этой проблемы, поскольку Corel эта версия программы больше не продается и не поддерживается.^[22]
• В 23:31:30 UTC в пятницу, 13 февраля 2009 г., десятичный представление времени Unix достигнуто 1234567890 секунд.^[23] Google отпраздновал это с Google каракули.^[24] Вечеринки и другие торжества проводились по всему миру, среди различных технических субкультур, чтобы отпраздновать 1234567890-я секунда.^[17][25]
• В среду, 18 мая 2033 года в 03:33:20 UTC, значение времени Unix будет равно 2000000000 секунд.
• В 06:28:16 UTC в четверг, 7 февраля 2036 г., Сетевой протокол времени перейдет к следующей эпохе, поскольку 32-битное значение отметки времени, используемое в NTP (без знака, но основанное на 1 января 1900 г.), будет переполняться. Эта дата близка к следующей дате, потому что 136-летний диапазон 32-битного целого числа секунд почти в два раза превышает 70-летний сдвиг между двумя эпохами.
• В 03:14:08 UTC во вторник, 19 января 2038 года, 32-разрядные версии метки времени Unix перестанут работать, так как она переполнит наибольшее значение, которое может содержаться в 32-разрядном числе со знаком (7FFFFFFF16 или же 2147483647 ). До этого момента программное обеспечение, использующее 32-битные метки времени, должно было принять новое соглашение для меток времени,^[26] а форматы файлов, использующие 32-битные отметки времени, необходимо будет изменить для поддержки более крупных отметок времени или другой эпохи. Если не изменить, следующая секунда будет неправильно интерпретирована как 20:45:52 Пятница. 13 декабря 1901 г.. Это называется Проблема 2038 года.
• В 05:20:00 UTC в субботу, 24 января 2065 г., значение времени Unix будет равно 3000000000 секунд.
• В 06:28:15 UTC в воскресенье, 7 февраля 2106 года, время Unix достигнет FFFFFFFF16 или же 4294967295 секунд, что для систем, в которых время хранится на 32-битных целых числах без знака, является максимально достижимым. Для некоторых из этих систем следующая секунда будет неправильно интерпретирована как 00:00:00 четверг. 1 января 1970 года UTC. В других системах может возникнуть ошибка переполнения с непредсказуемыми результатами.^{[нужна цитата ]}
• В воскресенье, 4 декабря, в 15:30:08 UTC. 292277026596,^[27][28] 64-битные версии метки времени Unix перестают работать, поскольку она переполняет самое большое значение, которое может содержаться в 64-битном числе со знаком. Это почти в 22 раза больше расчетный текущий возраст Вселенной, который 1.37×10¹⁰ лет (13,7 млрд).

В литературе и календаре

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

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

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

Примечания

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

Рекомендации

1. «Базовые спецификации Open Group, выпуск 7, Обоснование: базовые определения, раздел A.4 Общие концепции». Открытая группа. Получено 9 сентября 2019.
2. «Базовые спецификации Open Group, выпуск 7, раздел 4.16 секунд с начала эпохи». Открытая группа. Получено 22 января 2017.
3. Мэтью, Нил; Камни, Ричард (2008). «Среда Linux». Начало программирования для Linux. Индианаполис, Индиана, США: Wiley. п. 148. ISBN  978-0-470-14762-7.
4. «Базовые спецификации Open Group, выпуск 7, обоснование, раздел 4.16 секунд с начала эпохи». OpenGroup. Получено 22 января 2017.
5. Дата - Справочник по командам и утилитам, Единая спецификация UNIX, Выпуск 7 из Открытая группа
6. «Конвертер эпохи - Конвертер временных меток Unix». Конвертер эпохи. Получено 12 января 2020.
7. «Обработка отметок времени с помощью формата даты в ярлыках». Apple Inc.. Получено 19 июн 2019.
8. "Формат даты RAW в отчетах, экспортированных в CSV". Международная корпорация бизнес-машин (IBM). Получено 19 июн 2019.
9. «TIMESTAMP BY (Azure Stream Analytics)». Корпорация Майкрософт. Получено 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. Маккарти, Д.; Зайдельманн, П. К. (2009). ВРЕМЯ - от вращения Земли к атомной физике. Вайнхайм: Wiley – VCH Verlag GmbH & Co. KGaA. п. 232. ISBN  978-3-527-40780-4.
16. Руководство программиста Unix (PDF) (1-е изд.). 3 ноября 1971 г.. Получено 28 марта 2012. время возвращает время с 00:00:00 1 января 1971 г., измеренное в шестидесятых долях секунды.
17. Твини, Дилан (12 февраля 2009 г.). "Любители Unix весело провести время, как будто это 1234567890". Проводной.
18. "Slashdot | дата +% s Превращение 1111111111". 17 марта 2005 г.^{[ненадежный источник? ]}
19. "Факты и мелочи о времени Unix - Время Unix. Информация". Архивировано из оригинал 27 октября 2017 г.
20. «UNIX приближается к зрелой старости в один миллиард». Электромагнитный.нет. Архивировано из оригинал 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". Времена.
26. "Unix Time Stamp.com". UnixTimeStamp.com. Получено 12 января 2020.
27. Спинеллис, Диомидис (7 апреля 2006 г.). Качество кода: перспектива открытого исходного кода. ISBN  9780321166074.
28. Рабочий документ IDRBT № 9 Y2K38 - Ашутош Саксена и Санджай Рават
29. Маши, Джон Р. (27 декабря 2004 г.). «Языки, уровни, библиотеки и долголетие». Очередь. 2 (9): 32–38. Дои:10.1145/1039511.1039532. S2CID  28911378.

внешняя ссылка

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