Время в формате unixtime 1с
Unix-время (англ. Unix time, также POSIX-время или Unix epoch или Unix time или Unix timestamp) — система описания моментов во времени, принятая в Unix и других POSIX-совместимых операционных системах. Определяется как количество секунд, прошедших с полуночи (00:00:00 UTC) 1 января 1970 года (четверг); время с этого момента называют «эрой Unix» (англ. Unix Epoch).
Период времени | Секунды |
---|---|
1 минута | 60 секунд |
1 час | 3600 секунд |
1 день | 86400 секунд |
1 неделя | 604800 секунд |
1 месяц (30.44 дней) | 2629743 секунд |
1 год (365.24 дня) | 31556926 секунд |
Unix Timestamp (временная метка) – это "зафиксированное" время, конкретная дата, запечатленная в числе c точностью до секунды.
UTC (англ. Coordinated Universal Time) - это Всемирное координированное время, которое "фиксируется" на нулевом меридиане (Лондон), и от которого ведется отсчет географических часовых поясов. Аббревиатура UTC не имеет конкретной расшифровки.
GMT (англ. Greenwich Mean Time) - Среднее время по Гринвичу, или гринвичское время. Соответствует нулевому часовому поясу (UTC 0). — среднее солнечное время меридиана, проходящего через прежнее место расположения Гринвичской королевской обсерватории около Лондона.
Границы Unix времени
В момент времени 00:00:00 UTC 1 января 1970 года (четверг) Unix-время равно нулю. Начиная с этого времени, число возрастает на определённое количество в день. Таким образом, к примеру, 16 сентября 2004 года в 00:00:00, спустя 12677 дней после начала отсчета Unix-времени, время будет представлено числом 12677 × 86400 = 1095292800. Расчеты могут быть также произведены в обратном направлении используя отрицательные числа. К примеру, дата 4 октября 1957 года 00:00:00, а это 4472 дня до начала отсчета представлена в Unix-времени числом −4472 × 86400 = −386380800
В программах для хранения Unix-времени используется целочисленный знаковый тип. 32-битные числа со знаком могут ссылаться на моменты времени от пятницы 13 декабря 1901 года 20:45:52 до вторника 19 января 2038 года 03:14:07 включительно.
UNIX-время или POSIX-время (англ. Unix time) - способ кодирования времени, принятый в UNIX и других POSIX-совместимых операционных системах.
Моментом начала отсчёта считается полночь (по UTC) с 31 декабря 1969 года на 1 января 1970, время с этого момента называют "эрой UNIX" (англ. Unix Epoch).
Время UNIX согласуется с UTC, в частности, при объявлении високосных секунд UTC соответствующие номера секунд повторяются.
Способ хранения времени в виде количества секунд очень удобно использовать при сравнении дат (с точностью до секунды), а также для хранения дат: при необходимости их можно преобразовать в любой удобочитаемый формат. Дата и время в этом формате также занимают очень мало места (4 или 8 байтов, в зависимости от размера машинного слова), поэтому его разумно использовать для хранения больших объёмов дат. Недостатки в производительности могут проявиться при очень частом обращении к элементам даты, вроде номера месяца и т. п. Но в большинстве случаев эффективнее хранить время в виде одной величины, а не набора полей.
Обычная дата(Human readable time) | Секунды |
1 минута | 60 секунд |
1 час | 3600 секунд |
1 день | 86400 секунд |
1 неделя | 604800 секунд |
1 месяц (30.44 дней) | 2629743 секунд |
1 год (365.24 дней) | 31556926 секунд |
Конвертивание эпохи Unix в человекопонятную дату(human readable date)
Unix дата начала и конца года, месяца или дня
Перевод секунд в дни, часы и минуты
Как получить Unix время в.
Конвертирование даты в Unix время в.
PHP | mktime(часы, минуты, секунды, месяц, день, год) |
Ruby | Time.local(год, месяц, день, часы, минуты, секунды, usec ) (или Time.gm для GMT/UTC вывода). Чтобы вывести добавьте .to_i |
Python | import time сначала, потом int(time.mktime(time.strptime('2000-01-01 12:34:00', '%Y-%m-%d %H:%M:%S'))) |
Java | long epoch = new java.text.SimpleDateFormat ("dd/MM/yyyy HH:mm:ss").parse("01/01/1970 01:00:00"); |
VBScript/ASP | DateDiff("s", "01/01/1970 00:00:00", поле даты) |
MySQL | SELECT unix_timestamp(время) Формат времени: YYYY-MM-DD HH:MM:SS или YYMMDD или YYYYMMDD |
PostgreSQL | SELECT extract(epoch FROM date('2000-01-01 12:34')); С timestamp: SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40-08'); C интервалом: SELECT EXTRACT(EPOCH FROM INTERVAL '5 days 3 hours'); |
SQL Server | SELECT DATEDIFF(s, '1970-01-01 00:00:00', поле с датой) |
Unix/Linux | date +%s -d"Jan 1, 1980 00:00:01" |
Конвертирование Unix времеми в понятную дату(human readable date).
PHP | date(Формат, unix время); |
Ruby | Time.at(unix время) |
Python | import time сначала, потом time.strftime("%a, %d %b %Y %H:%M:%S +0000", time.localtime(unix время)) Замените time.localtime на time.gmtime для GMT даты. |
Java | String date = new java.text.SimpleDateFormat("dd/MM/yyyy HH:mm:ss").format(new java.util.Date (unix время*1000)); |
VBScript/ASP | DateAdd("s", unix время, "01/01/1970 00:00:00") |
PostgreSQL | SELECT TIMESTAMP WITH TIME ZONE 'epoch' + unix время * INTERVAL '1 second'; |
MySQL | from_unixtime(unix время, не обязательно, выходной формат) Стандартный формат выхода YYY-MM-DD HH:MM:SS |
SQL Server | DATEADD(s, unix время, '1970-01-01 00:00:00') |
Microsoft Excel | =(A1 / 86400) + 25569 Результат будет в GMT зоне времени. Для других временных зон: =((A1 +/- разница аремени для зоны) / 86400) + 25569. |
Linux | date -d @1190000000 |
Другие OS | Командная строка: perl -e "print scalar(localtime(unix время))" (Если установлен Perl) Замените 'localtime' на 'gmtime' для GMT/UTC зоны времени. |
Для чего нужен инструмент "Unixtime конвертер"?
Данный инструмент, в первую очередь, будет полезен веб-мастерам, которые постоянно имеют дело с большими объемами дат или часто в своей работе обращаются к их элементам. С помощью инструмента "Unixtime конвертер" можно легко конвертировать Unix время в понятную для пользователя дату (и наоборот), узнать текущее Unix epoch время, а также получить Unix время в различных языках программирования, СУБД и операционных системах.
Что такое Unix время?
Эра Unix (Unix epoch) началась в ночь с 31 декабря 1969 года на 1 января 1970 года. Именно эту дату взяли за точку отсчета "компьютерного" времени, которое исчисляется в секундах и занимает очень мало места на диске – всего 4 или 8 байт. С помощью такого способа кодирования программисты могут "спрятать" любую дату в одно число, и легко конвертировать его обратно в понятный пользователям формат.
Unix время (еще его называют Unix time или POSIX time) удобно использовать в различных операционных системах и языках программирования, так как оно отображается в виде одной величины, а не определенного количества полей, занимающих место. К тому же, UNIX time полностью соответствует стандарту UTC (в том числе и в високосных годах) – в таком случае соответствующие значения секунд просто повторяются.
Терминология Unix
Пару слов о терминах.
Итак, Unix-временем (или POSIX-временем) считается количество секунд, которые прошли с полуночи 1 января 1970 года до настоящего времени.
Unix Timestamp (временная метка) – это "зафиксированное" время, иными словами – конкретная дата, запечатленная в числе.
UTC (Universal Coordinated Time) – это Всемирное координированное время, которое "фиксируется" на нулевом меридиане, и от которого ведется отсчет географических часовых поясов.
Насколько "долговечна" данная система?
Всего лишь через пару десятков лет, а именно 19 января 2038 года в 03:14:08 по UTC Unix time достигнет значения 2147483648, и компьютерные системы могут интерпретировать это число как отрицательное. Ключ к решению данной проблемы лежит в использовании 64-битной (вместо 32-битной) переменной для хранения времени. В таком случае, запаса числовых значений Unix time хватит человечеству еще на 292 миллиарда лет. Неплохо, правда?
Unix время – одно для всех
Если вы живете в Лондоне или Сан-Франциско, а ваши друзья – в Москве, то "сверить часы" можно по Unix time: эта система в данный момент времени едина для всего мира. Естественно, если время на серверах выставлено правильно. А с помощью инструмента "Unixtime конвертер" такая конвертация займет у вас доли секунды.
Почему Unix время начинается с 1 января 1970 года
Все дело в том, что Unix время начинает отсчет эпохи Unix, с выпуска первой UNIX системы. Первая система подобного рода была создана в 1969 году, поэтому точкой отсчета времени разработчики приняли дату с 1 января 1970 года в полночь по UTC (Всемирное координированное время).
Давайте разберемсяс тем, для чего нужны Unix время и Unix Timestamp, а также дадим им четкие понятия.
Unix время – это текущее количество секунд прошедших с 1 января 1970 года.
Unix Timestamp – это метка времени, которая представляет собой последовательность символов, отражающих количество секунд, прошедших с 1 января 1970 года.
Попробую привести пример, для разъяснения разницы этих двух понятий.
На время написания мной данного поста, Unix время было равно 1346765877.
Откровенно говоря, особого смысла разделять два понятия, на мой взгляд, нет, но все же полезно иметь представление о том, что из-себя представляет Unix Time, а также полезно понимать, что количество максимально возможных секунд прошедших с 1970 года, имеет предел!
Конец эпохи Unix придёт в 2038 году
Факт: максимальным двоичным числом в 32 битных системах является число 01111111 11111111 11111111 11111111, переведя его в десятичную систему, мы получим число 2147483647.
19 января 2038 года в 03:14:08 настанет момент, когда количество секунд прошедших с начала эры Unix, превысит максимальное, доступное в 32 битной системе, число = 2147483647. При переполнении разряда, произойдет сброс даты.
Проверить эту теорию на наглядном примере очень просто:
- Откройте стандартный калькулятор Windows нажмите ALT+3 , этим вы переведете его в инженерный вид;
- Установите 4 байтовый режим, и десятичный тип ввода;
- Напишите число 2147483647 ;
- Обратите внимание, на представление числа в двоичной системе;
- Прибавьте к числу единицу;
- Результатом сложения окажется отрицательное число!
Если продолжить добавлять единицу, то мы получим циклическое замыкание.
Именно такое кольцевание дат произойдет с 19 января 2038 года на всех системах использующих 32 битную архитектуру.
На самом деле не стоит печалиться, ведь разработчики вычислительных систем все больше внедряют 64 битные архитектуры в повсеместное использование. Будем верить в то, что они успеют к 2038 году.
Теперь поговорим об использовании unix timestamp в php, mysql и даже в javascript.
Работа с unix timestamp
Очень важным моментом, при работе с unix timestamp в php или mysql, является необходимость четкого понимать плюсы и минусы такого формата даты.
Например, TIMESTAMP не получится использовать для задания исторических событий или событий далекого будущего. Весь набор дат ограничен периодом с 1970 по начало 2038 года. Если задать дату, выходящую за рамки 2038, она будет не правильно интерпретирована 32 битной системой.
Осознав это ограничение, напрашивается логический вопрос: "Зачем нужно заморачиваться с представлением даты в секундах?"
Когда следует использовать Unix Timestamp
Для представления времени в обычной для нас системе его измерения, требуется 8 байт, а для unix timestamp вдвое меньше – 4 байта.
Экономия объема данных, на мой взгляд, основной и неоспоримый плюс в использовании Unix Time.
Кроме того есть ряд полезных нюансов доступных при работе с UNIX timestamp в mysql. А поскольку вся информация должна храниться на сервере баз данных, и он в свою очередь имеет ряд преимуществ, при работе с метками Unix времени, то выбор в сторону unix timestamp можно корректно обосновать следующими положениями.
В MySQL предусмотрен соответствующий тип данных Timestamp для работы с форматом unix-времени, установив который мы сразу получаем полезное преимущество, перед стандартными форматами DATE и DATETIME. Преимущество заключается в том, что выполняя операцию добавления новой записи в таблицу, столбец с этим типом данных заполняется автоматически. А это значит, что мы можем сэкономить не только на объеме данных, но и на процессорном времени веб сервера.
Для подкрепления слова делом поставим такую задачу: при регистрации нового пользователя в системе, нужно заносить дату его добавления в базу данных.
Если тип поля хранящего дату в таблице – DATETIME, то запрос из PHP скрипта будет выглядеть примерно так:
В случае, когда поле date имеет тип TIMESTAMP запрос будет таким:
Есть и минус: если полей типа TIMESTAMP несколько, автоматом обновляется, только, первое.
Есть ли смысл использовать INT вместо timestamp
Многие программисты при работе с unix timestamp, используют целочисленный формат int(11) . Это совершенно не рациональный подход к вопросу, поскольку в MySQL для типа timestamp предусмотрено множество полезных функций, влияющих на скорость работы с ним. Поэтому храня, метку времени в INT, мы лишим себя всяческой серверной поддержки этого формата. Это примерно, тоже, что хранить id в типе varchar(11) .
Тем не менее, есть одно оправдание хранения unix timestamp в INT. При переносе базы между разными СУБД, может возникнуть конфликт типов, т.е. для одной из СУБД тип timestamp может оказаться незнакомым. В этом случае использование int будет иметь преимущество, поскольку данный формат есть во всех СУБД.
Краткая характеристика календарных типов MySQL
Перевод даты в unix
Пришло время выложить несколько полезных функций по переводу даты в unix timestamp и обратно из unix-time в читабельную дату.
Вчера Дэнни поинтересовался любопытными фактами о Unix-времени, а я вспомнил, что иногда оно работает совершенно неинтуитивно.
Вот эти три факта кажутся в высшей степени разумными и логичными, не так ли?
- Время Unix — это количество секунд с 1 января 1970 года 00:00:00 UTC.
- Если подождать ровно одну секунду, то время Unix изменится ровно на одну секунду.
- Время Unix никогда не двигается назад.
У всех трёх заблуждений одна причина: високосные секунды. Если вы не знакомы с дополнительными секундами, вот краткая справка:
Время UTC определяется двумя факторами:
-
: усреднённые показания сотен атомных часов по всему миру. Мы можем измерить секунду по электромагнитным свойствам атома, и это самое точное измерение времени, известное науке.
, основанное на вращении Земли вокруг собственной оси. Один полный оборот — одни сутки.
Когда два времени выпадают из синхрона, в UTC добавляется или удаляется секунда, чтобы вернуть синхронизацию. С 1972 года служба IERS (которая управляет этим делом) добавила 27 дополнительных секунд. В результате получилось 27 суток UTC продолжительностью в 86 401 секунду. Теоретически возможно появление суток продолжительностью 86 399 секунд (минус одна). Оба варианта противоречат фундаментальному предположению о Unix-времени.
Время Unix предполагает, что каждый день длится ровно 86 400 секунд (60 × 60 × 24 = 86 400), без всяких дополнительных секунд. Если происходит такой скачок, то время Unix либо перепрыгивает через секунду, либо отсчитывая две секунды за одну. По состоянию на 2019 год в нём отсутствует 27 високосных секунд.
Так что наши заблуждения нужно дополнить следующим образом:
- Время Unix — это количество секунд с 1 января 1970 00:00:00 UTC минус високосные секунды.
- Если подождать ровно одну секунду, время Unix изменится ровно на одну секунду, если не была удалена дополнительная секунда.
До сих пор на практике секунды никогда не удалялись (и замедление вращения Земли означает, что это маловероятно), но если бы это когда-либо произошло, это означало бы, что день UTC стал на одну секунду короче. В этом случае последняя секунда UTC (23:59:59) отбрасывается.
В каждых сутках Unix одинаковое количество секунд, поэтому последняя Unix-секунда укороченного дня не будет соответствовать никакому времени UTC. Вот как это выглядит, в интервалах по четверти секунды:
Это уже 27 раз произошло на практике. По окончании суток UTC добавляют дополнительную секунду 23:59:60. В сутках Unix одинаковое количество секунд, поэтому он не может добавить дополнительную секунду — вместо этого приходится повторять метки времени Unix для последней секунды. Вот как это выглядит, в интервалах по четверти секунды:
Читайте также: