Формат времени unix: Онлайн Unix time конвертер

Unix time stamp — UNIX-время или POSIX-время (англ. Unix time) — система описания моментов во времени, принятая в UNIX и других POSIX-совместимых операционных системах. Моментом начала отсчёта считается полночь (по UTC) с 31 декабря 1969 года на 1 января 1970 года, время с этого момента называют «эрой UNIX» (англ. Unix Epoch). Время UNIX согласуется с UTC, в частности, при объявлении високосных секунд UTC соответствующие номера секунд повторяются. Способ хранения времени в виде количества секунд очень удобно использовать при сравнении дат (с точностью до секунды), а также для хранения дат: при необходимости их можно преобразовать в любой удобочитаемый формат. Дата и время в этом формате также занимают очень мало места (4 или 8 байтов, в зависимости от размера машинного слова), поэтому его разумно использовать для хранения больших объёмов дат. Недостатки в производительности могут проявиться при очень частом обращении к элементам даты, вроде номера месяца и т. п. Но в большинстве случаев эффективнее хранить время в виде одной величины, а не набора полей. Чтобы узнать текущее UNIX-время в большинстве UNIX-подобных систем, можно использовать команду date +%s. 13 февраля 2009 года в 23:31:30 по UTC (02:31:30 14 февраля по MSK) значение UNIX-времени достигло 1234567890 секунд. 19 января 2038 года в 03:14:08 по всемирному времени значение переменной типа time_t, отсчитывающей число секунд, прошедших с 1 января 1970 года, достигнет 2^31 (2147483648), что может привести к ошибочной интерпретации этого числа как отрицательного. Возможное решение данной проблемы состоит в использовании не 32-битной, а 64-битной переменной для хранения времени, чего хватит ещё на 300 миллиардов лет.

Важно — не все знают что «unix time stamp» в один момент времени един для всего мира, тоесть если проверить time на сервере в России и например на сервере в USA, то значение будет одно и тоже(естественно при условии что на обоих серверах время выставлено верно), отличается только преобразование его в понятное для людей значение в зависимости от настроек сервера, и естественно обратное приобразование тоже будет отличаться если не задан часовой пояс.

Конвертер времени эпохи Unix (Timestamp) в обе стороны

Unix Epoch – Timestamp конвертер времени онлайн

Международный формат времени Unix Epoch – общепризнанный эталон, который используется в сфере программирования и компьютерных технологий. Нередко и дату, и время можно увидеть не в привычном для людей виде, а как набор цифр – секунд, прошедших с 1 января 1970 года, когда был дан старт новой системе. Чтобы было легче работать с UNIX, мы создали 4 удобных конвертера времени – они функционируют онлайн, на 100% бесплатны и максимально точны.

Зачем нужен конвертер времени формата UNIX?

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

• конвертировать обычную дату в Unix Timestamp;
• узнать точное время в секундах на начало конкретной даты;
• перевести секунды в дни, часы, минуты;
• определить, сколько сейчас времени по UNIX.

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

Как перевести время UNIX в человеческую дату?

Если нужно конвертировать заданное количество секунд в человеческую дату, сделать это довольно просто:

1. Укажите исходные данные без пробелов.
2. Кликните «Timestamp в обычную дату».
3. Посмотрите результат – дату и точное время по GMT.
4. Ниже увидите результат расчетов для вашей временной зоны – то есть, то время, которое было в регионе, где сейчас находитесь.

Кстати, можно задать любое число секунд, поэкспериментируйте с красивыми или круглыми числами, чтобы узнать, какая при этом будет дата в общепринятом формате. Так называемый «юбилей» времени по UNIX – настоящее событие мирового масштаба.

Как конвертировать онлайн обычную дату в формат Timestamp?

Еще одна возможность сервиса – перевод даты в Timestamp, операция обратная для предыдущей, позволяет конвертировать любое число в секунды. Чтобы воспользоваться функцией, необходимо:

1. Задать дату в поле для ввода – можно ввести вручную или использовать календарь.
2. Указать часы, минуты, секунды по GMT – будьте внимательны, может отличаться от времени в вашем часовом поясе.
3. Нажмите «Дату в Timestamp».
4. Сервис автоматически переведет дату и время в секунды – ознакомьтесь с результатом.

Чтобы конвертер времени UNIX работал корректно, можно задать любую дату, но не ранее 1 января 1970 года, иначе результат будет отрицательным.

Как узнать начало и конец для даты в UNIX-времени?

Полезной для пользователей является функция нахождения времени UNIX на начало и конец заданного временного промежутка. Чтобы узнать Timestamp, нужно:

1. Выбрать, какой временной промежуток интересует – год, месяц или день.
2. Указать количество дней, месяцев, лет в человеческом формате.
3. Нажать «Конвертировать в UNIX».
4. Получить результат на начало и конец указанного периода в секундах.

Если хотите получить результат для точной даты, а не года или месяца, проставляйте флажок напротив слова «день», иначе сервис будет считать секунды на начало месяца или года.

Как перевести секунды в дни, часы, минуты онлайн?

Наш сервис также легко конвертирует секунды UNIX в дни, часы и минуты без указания точной даты – только времени, которое прошло с запуска часов. Для расчетов следует:

1. Задать нужное число – секунды времени.
2. Нажать «Конвертировать в дни, часы и минуты».
3. Программа выполнит перевод с точностью до секунды.

Мы создали конвертер времени эпохи Unix Epoch, чтобы посетителям было проще работать с этим форматом. Если вам приходится хотя бы иногда переводить секунды в обычное время, добавьте страницу в закладки, чтобы не потерять. Ресурс полностью бесплатный и удобный, а еще здесь есть десятки других классных сервисов, включая метроном, будильник, таймер – и все они работают онлайн без установки на компьютер.

Unix TimeStamp Online — конвертер дат

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

Конвертирование TimeStamp → обычная дата

Прямо сейчас, во время загрузки этой страницы, Unix Time Stamp равен 1601742692.

Введите число Unix TimeStamp:

  Конвертировать в дату | Текущая дата | Очистить

Дата: не известно

Внимание! В качестве временного ориентира в моем скрипте используется часовой пояс Москвы (МСК, Europe/Moscow, UTC +4). Обязательно учитывайте это, если вам нужна предельная точность в отображаемом времени.

Конвертирование Дата → Unix TimeStamp

Введите дату:

Unix TimeStamp: не известно

Внимание! В качестве временного ориентира в моем скрипте используется часовой пояс Москвы (МСК, Europe/Moscow, UTC +4). Обязательно учитывайте это, если вам нужна предельная точность в отображаемом времени.

Не понимаете, зачем это нужно? Тогда немного теории.

Этот инструмент нужен для того, что бы перевести дату из формата Unix TimeStamp в понятную человеку дату и наоборот.

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

Unix время (или TimeStamp, что в переводе на русский означает «отметка времени» и имеет тот же смысл) — это количество секунд, прошедших с 1 января 1970 года.
То есть Unix TimeStamp на момент 01.01.1970 00:00:00 было равно 0. Через 2 минуты (120 секунд) Unix-время было равно уже 120.
Например, сутками позже (02.01.1970 00:00:00) Unix время было равно уже 86400, так как прошло 60*60*24=86400 секунд.
Сейчас Unix Time Stamp равно уже 1601742692 и число постоянно растет, так как секунды постоянно тикают.

Но зачем им пользоваться? Все дело в том, что Unix TimeStamp удобно использовать для хранения и манипуляции датой при программировании.
Не буду вдаваться в подробности, но если вкратце то, что число намного удобнее считать и сравнивать, чем строку с «левыми» символами.
Именно поэтому большинство разработчиков используют именно Unix TimeStamp для работы с датой в своих проектах и в базе данных мы часто в поле `date` видим одно какое-то очень большое число, совсем не похожее на дату.

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

Проблема 2038 года

Как я уже и говорил, число Unix TimeStamp с каждой секундой становится больше на 1. Рано или поздно должен наступить предел этого числа и будет это как раз в 2038 году. Все дело в том, что максимальным числом в распространенных в начале 21 века 32-битных операционных системах является 2³¹. Именно этого числа и достигнет Unix TimeStamp в 2038 году.

→ А решение это проблемы уже найдено. Для того, что бы в 2038 году сайты не перестали корректно учитывать время, достаточно пользоваться 64-битной операционный системой на хостинге/VDS/выделенном сервере, а не 32-битной. С активно растущими мощностями компьютеров и уменьшением их стоимости все идет к тому, что к 2038 году подавляющее большинство услуг в сфере предоставления пространства под сайт будут предоставляться на основе 64-битных ОС. Кстати, в 64-битной системе подобная проблема не коснется нас как минимум 292 млрд лет, чего вполне достаточно для того, что бы считать проблему 2038 года решенной.

Форматы времени в MySQL: TIMESTAMP vs DATE[TIME]

В MySQL 5 есть несколько типов данных для хранения даты и времени. Это TIMESTAMP, DATE, DATETIME, TIME и YEAR. Все они обладают своими особенностями, и выбор в пользу того или иного календарного типа должен производиться отдельно в каждой конкретной ситуации. Я хотел бы поделиться с вами результатом моего сегодняшнего миниисследования этих типов, в том числе в аспекте работы с временными зонами.Итак, все календарные типы данных подробно описаны в разделе «10.3. Date and Time Types» руководства по MySQL. А важная информация, касающаяся поддержки СУБД временных зон, расписана в разделе «9.7. MySQL Server Time Zone Support». Все следующее далее базируется на изучении руководства. В то же время, в здесь указаны лишь нюансы выбора в пользу того или иного типа, поэтому этот материал никак не заменяет мануал, но дополняет его.

Вначале краткая характеристика каждого из типов:

• TIMESTAMP — тип данных для хранения даты и времени. Данные хранятся в виде количества секунд, прошедших с начала «эпохи Юникса». Диапазон значений: 1970-01-01 00:00:00 — 2038-12-31 00:00:00. Занимает 4 байта.
• YEAR — тип данных для хранения года. Диапазон значений: 1901 — 2155. Занимает 1 байт.
• DATE — тип данных для хранения даты. Диапазон значений: 1000-01-01 — 9999-12-31. Занимает 3 байта.
• TIME — тип данных для хранения времени. Диапазон значений: −828:59:59 — 828:59:59. Занимает 3 байта.
• DATETIME — тип данных для хранения даты и времени. Диапазон значений: 1000-01-01 00:00:00 — 9999-12-31 00:00:00. Занимает 8 байт.

Хозяйке на заметку. Интересно то, что большинство программистов полагают, что понятие «timestamp» — это и есть Unix-время. На самом же деле, timestamp — это метка, которая представляет собой последовательность символов, обозначающих дату и / или время, когда определенное событие произошло. А «время Юникса» (Unix time) или POSIX time — это количество секунд, прошедших с полуночи 1 января 1970 года по UTC. Понятие timestamp шире, чем Unix time.

Проанализировав описание типов, представленное выше, можно сделать практически все выводы о достоинствах и недостатках тех или иных типов. Все довольно просто и очевидно.

Но прежде, чем рассказать об использовании этих типов, хочу заметить, что на практике часто используется другой тип для хранения даты и времени: целочисленное значение (для хранения даты — INT (4 байта), даты и времени — BIGINT (8 байт)). Отличие использования целочисленных типов от DATE и DATETIME лишь в том, что при выводе данные не форматируются, а в вычислениях с датами и временем целые числа требуется преобразовывать в соответствующий календарный тип. Кроме того, не производится проверка на валидность представленного значения перед сохранением. Возможности сортировки сохраняются. Поэтому INT и BIGINT имеет смысл использовать в тех же случаях, как DATE и DATETIME, с целью максимизации переносимости и независимости от СУБД. Других преимуществ я не вижу, если они есть, предлагаю указать в комментах.

Использование календарных типов данный в MySQL

Начнем с самого простого — тип YEAR. Единственное его достоинство — малый размер — всего-то 1 байт. Но из-за этого действует строгое ограничение по диапазону допустимых значений (тип может хранить только 255 разных значений). Мне сложно представить практическую ситуацию, когда может потребоваться хранить года строго в диапазоне от 1901 до 2155. Кроме того, тип SMALLINT (2 байта) дает диапазон, достаточный в большинстве ситуаций для хранения года. А экономить 1 байт на строке в таблице БД в наше время смысла нет.

Типы DATE и DATETIME можно объединить в одну группу. Они хранят дату или дату и время с довольно широким диапазоном допустимых значений, независимую от установленной на сервере временной зоны. Их использование определенно имеет практический смысл. Но если требуется хранить даты исторических событий, уходящие в прошлое за Нашу эру, придется выбрать другие типы данных. Для хранения дат неких событий, потенциально выходящих за рамки диапазона типа TIMESTAMP (дни рождений, даты выпуска продуктов, избрания президентов, запуски космических ракет и т.д.), отлично подойдут эти типы. При использовании этих типов нужно учитывать один важный нюанс, но об этом ниже.

Тип TIME можно использовать для хранения промежутка времени, когда не нужна точность меньше 1 секунды, и промежутки времени меньше 829 часов. Добавить тут больше нечего.

Остался самый интересный тип — TIMESTAMP. Рассматривать его надо в сравнении с DATE и DATETIME: TIMESTAMP тоже предназначен для хранения даты и/или времени происхождения неких событий. Важное отличие между ними в диапазонах значений: очевидно, что TIMESTAMP не годится для хранения исторических событий (даже таких, как дни рождений), но отлично подходит для хранения текущих (логирование, даты размещения статей, добавления товаров, оформления заказов) и предстоящих в обозримом будущем событий (выходы новых версий, календари и планировщики и т.д).

Основное удобство использования типа TIMESTAMP состоит в том, что для столбцов этого типа в таблицах можно задавать значение по умолчанию в виде подстановки текущего времени, а так же установки текущего времени при обновлении записи. Если вам требуется эти возможности, то с вероятностью 99% TIMESTAMP — именно то, что вам нужно. (Как этоделать, смотрите в мануале.)

Не стоит бояться того, что с приближением к 2038 году ваш софт перестанет работать. Во-первых, до этого времени вашим софтом, скорее всего, просто перестанут пользоваться (особенно версиями, которые пишутся сейчас). Во-вторых, с приближением к этой дате разработчики MySQL обязательно что-нибудь придумают для сохранения работоспособности вашего софта. Все решится так же хорошо, как проблема Y2K.

Итак, тип TIMESTAMP используем для хранения дат и времени свершения событий нашего времени, а DATETIME и DATE — для хранения дат и времени свершения исторических событий, или событий глубокого будущего.

Диапазоны значений — это важное отличие между типами TIMESTAMP, DATETIME и DATE, но не главное. Главное то, что TIMESTAMP хранит значение в UTC. При сохранении значения оно переводится из текущего временной зоны в UTC, а при его чтении — во время текущей временной зоны из UTC. DATETIME и DATE хранят и выводят всегда одно и то же время, независимо от временных зон.

Временные зоны устанавливаются в СУБД MySQL глобально или для текущего подключения.Последнее можно использовать для обеспечения работы разных пользователей в разных временных зонах на уровне СУБД. Все значения времени физически будут храниться в UTC, а приниматься от клиента и отдаваться клинту — в значениях его временной зоны. Но только при использовании типа данных TIMESTAMP. DATE и DATETIME всегда принимают, хранят и отдают одно и то же значение.

Функция NOW() и ее синонимы возвращают значение времени в текущей временной зоне пользователя.

Учитывая все эти обстоятельства, необходимо быть крайне внимательными при изменении временной зоны в пределах подключения к серверу и использовании типов DATE и DATETIME. Если надо хранить дату (например, дату рождения), то никаких проблем не будет. Дата рождения в любой зоне одинаковая. Т.е. если вы родились 1 января в 0:00 UTC/GMT+0, то это не значит, что в Америке будут праздновать ваш день рождения 31 декабря. Но если вы решите хранить время события в столбце DATETIME, то тут уже построить работу с пользовательскими временными зонами на уровне СУБД просто не выйдет. Поясню на примере:

Пользователь X работает в зоне UTC/GMT+2, Y — в зоне UTC/GMT+3. Для соединений пользователей с MySQL установлена соответствующая (у каждого своя) временная зона. Пользователь размещает сообщение на форуме, нас интересует дата написания сообщения.

Вариант 1: DATETIME. Пользователь X пишет сообщение в 14:00 UTC/GMT+2. Значение в поле «дата» сообщения подставляется как результат выполнения функции NOW() — 14:00. Пользователь Y считывает время написания сообщения и видит те же 14:00. Но у него в настройках стоитзона UTC/GMT+3, и он думает, что сообщение было написано не только что, а час назад.

Вариант 2: TIMESTAMP. Пользователь X пишет сообщение в 14:00 UTC/GMT+2. В поле «дата» попадает результат выполнения функции NOW() — в данном случае — 12:00 UTC/GMT+0. ПользовательY считывает время написания сообщения и получает (UTC/GMT+3)(12:00 UTC/GMT+0) = 15:00 UTC/GMT+3. Все получается ровно так, как мы хотим. И главное — пользоваться этим крайне удобно: для поддержки пользовательских временных зон не нужно писать никакой код приведения времени.

Возможности подстановки текущего времени и работы с временными зонами в типе TIMESTAMP настолько весомы, что если вам в неком логе надо хранить дату без времени, все равно стоит использовать TIMESTAMP, вместо DATE, не экономя 1 байт разницы между ними. При этом на «00:00:00» просто не обращать внимания.

Если же вы не можете использовать TIMESTAMP из-за относительно малого диапазона его значений (а обычно это 1—2 случая против 10—15 в базе сайта), придется использовать DATETIME и аккуратно его корректировать значения в нужных местах (т.е. при записи в это поле переводить дату в UTC, а при чтении — во время в зоне считывающего пользователя). Если вы храните только дату, то скорее всего не важно, какая у вас временная зона: новый год все празднуют 1 января по локальному времени, ничего переводить тут не понадобится.

Время Unix — Unix time

Система определения моментов времени для компьютеров

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

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

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

Определение

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

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

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

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

Unix эпохи время 00:00:00  UTC 1 января 1970 года Существует проблема с этим определением, в том , что 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 является единственной эпохой (часто называемой « эпохой »), время Unix иногда называют временем эпохи .

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

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

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

Числа времени 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 секунду после прыжка. Это упрощает реализацию и описано в статье Миллса. Вот что происходит при положительной дополнительной секунде:

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

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

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

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

Вариант на основе TAI

Другой, гораздо более редкий и несовместимый вариант хронометража Unix включает в себя кодирование TAI, а не UTC; некоторые системы Linux настроены таким образом. Поскольку 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. Однако 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). Эти структуры обеспечивают десятичного -На фиксированной запятой формат данных, который полезен для некоторых приложений, и тривиальное для преобразования для других.

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

История

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

В руководстве пользователя также отмечается, что «хронологически мыслящий пользователь заметит, что 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. Это прямо аналогично празднованию Нового года, которое происходит при смене года во многих календарях. По мере того, как время использования Unix расширялось, росла и практика празднования его вех. Обычно отмечаются значения времени, представляющие собой круглые числа в десятичном формате, в соответствии с соглашением Unix о просмотре time_tзначений в десятичном формате . Среди некоторых групп также отмечаются круглые двоичные числа, например, +2 ^30, которое произошло в 13:37:04 UTC в субботу, 10 января 2004 года.

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

• В среду, 17 октября 1973 г., в 18:36:57 UTC впервые появилась дата в формате ISO 8601 (1973-10-17) в пределах цифр времени Unix (119731017).
• В воскресенье, 9 сентября 2001 г., в 01:46:40 UTC, Unix billennium (номер времени Unix 1 000 000 000 ). Название Billennium является контаминация из миллиардов и тысячелетия . Некоторые программы, которые сохраняли временные метки с использованием текстового представления, сталкивались с ошибками сортировки, например, при сортировке текста время после оборота, начиная с 1 цифры, ошибочно отсортировано до более раннего времени, начиная с 9 цифр. Затронутые программы включали популярный читатель Usenet KNode и клиент электронной почты KMail , часть среды рабочего стола KDE . Такие ошибки обычно носили косметический характер и быстро исправлялись, как только проблемы становились очевидными. Проблема также затронула многие фильтры Filtrix формата документа, поставляемые с версиями WordPerfect для Linux ; сообществом пользователей был создан патч для решения этой проблемы, поскольку Corel больше не продавала и не поддерживала эту версию программы.
• В 23:31:30 UTC в пятницу, 13 февраля 2009 г., десятичное представление времени Unix достигло1 234 567 890 секунд. Google отпраздновал это каракули Google . Вечеринки и другие торжества проводились по всему миру, среди различных технических субкультур, чтобы отпраздновать1 234 567 890- я секунда.
• В среду, 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-битные метки времени, должно было принять новое соглашение для меток времени, а форматы файлов, использующие 32-битные метки времени, необходимо будет изменить для поддержки больших меток времени или другой эпохи. Если не изменить, следующая секунда будет неправильно интерпретирована как 20:45:52 пятница 13 декабря 1901 года по всемирному координированному времени. Это называется проблемой 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 , 64-битные версии метки времени Unix перестают работать, так как она переполняет самое большое значение, которое может храниться в 64-битном числе со знаком. Это почти в 22 раза больше текущего возраста Вселенной , что составляет1,37 × 10 ¹⁰ лет (13,7 млрд).

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

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

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

Заметки

Ссылки

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

python — временная метка Unix в формате времени iso 8601

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.Формула

Excel: преобразование метки времени Unix в дату Excel

Метка времени Unix отслеживает время как текущее количество секунд. Отсчет начинается в «эпоху Unix» 1 января 1970 года, поэтому метка времени Unix — это просто общее количество секунд между любой заданной датой и эпохой Unix. Поскольку день содержит 86400 секунд (24 часа x 60 минут x 60 секунд), преобразование во время Excel может быть выполнено путем деления дней на 86400 и добавления значения даты 1 января 1970 года.

В показанном примере формула сначала делит значение отметки времени в B5 на 86400, а затем добавляет значение даты для эпохи Unix, 1 января 1970 г.Формула вычисляется так:

 
 = (B5 / 86400) + ДАТА (1970,1,1)
= (1538352000/86400) +25569
= 43374 
 Если C5 отформатирован с использованием даты Excel «д-ммм-гггг», дата отображается как 1 октября 2018 г.
 Как Excel отслеживает даты и время 
 Система дат Excel начинается 1 января 1900 года и ведет отсчет вперед. В таблице ниже показаны числовые значения, связанные с несколькими случайными датами:
 Дата
 Исходное значение
 1 января 1900
 1
 28 июля 1914 г. 00:00
 5323
 1 января 1970 г. 00:00
 25569
 31 декабря 1999 г.
 36525
 1 октября 2018 г.
 43374
 1 октября 2018 г. 12:00
 43374.5
 Обратите внимание, что последняя дата также включает время. Поскольку один день равен 1, а один день равен 24 часам, время в Excel можно представить в виде дробных значений от 1, как показано в таблице ниже. Чтобы увидеть значение, отображаемое как время, необходимо применить формат времени.
 Часы
 Время
 Фракция
 Значение
 3
 3:00
 3/24
 0.125
 6
 6:00
 6/24
 0,25
 4
 4:00
 4/24
 0,167
 8
 8:00
 8/24
 0,333
 12
 12:00
 12/24
 0,5
 18
 18:00
 18/24
 0.75
 21
 21:00
 21/24
 0,875
 24
 00:00
 24/24
 1
.
 python — Каков самый простой способ получить текущее время по Гринвичу в формате временной метки Unix? 
 Переполнение стека
 Около
 Продукты
 Для команд
 Переполнение стека
 Общественные вопросы и ответы
 Переполнение стека для команд
 Где разработчики и технологи делятся частными знаниями с коллегами
 Вакансии
 Программирование и связанные с ним технические возможности карьерного роста
 Талант
 Нанимайте технических специалистов и создавайте свой бренд работодателя
 Реклама
 Обратитесь к разработчикам и технологам со всего мира
 О компании
 .
No related posts.