Unix time конвертер (Конвертер времени Unix онлайн)
Что такое Unix время или Unix эпоха (Unix epoch или Unix time или POSIX time или Unix timestamp) ?
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 время в.
| Perl | time |
| PHP | time() |
| Ruby | Time.now (или Time.new ). Чтобы вывести: Time.now.to_i |
| Python | import time сначала, потом time.time() |
| Java | long epoch = System.currentTimeMillis()/1000; |
| Microsoft .NET C# | epoch = (DateTime.Now.ToUniversalTime().Ticks — 621355968000000000) / 10000000; |
| VBScript/ASP | DateDiff(«s», «01/01/1970 00:00:00», Now()) |
| Erlang | calendar:datetime_to_gregorian_seconds(calendar:now_to_universal_time( now()))-719528*24*3600. |
| MySQL | SELECT unix_timestamp(now()) |
| PostgreSQL | SELECT extract(epoch FROM now()); |
| SQL Server | SELECT DATEDIFF(s, ‘1970-01-01 00:00:00’, GETUTCDATE()) |
| JavaScript | Math.round(new Date().getTime()/1000.0) getTime() возвращает время в миллисекундах. |
| Unix/Linux | date +%s |
| Другие OS | Командная строка: perl -e «print time» (Если Perl установлен на вашей системе) |
Конвертирование даты в 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-временем (или 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 конвертер» такая конвертация займет у вас доли секунды.
Источник
Особенности работы со временем в различных временных зонах
Работа с различными типа данных в базах данных
MYSQL
В mysql существует несколько стандартных типов данных для представления времени, мы рассмотрим TIMESTAMP и DATETIME .
В документации говорится, что к некоторым типам данных применяется политика конвертирования, а к некоторым — нет.
На практике все намного интереснее. Рассмотрим несколько примеров:
Создадим таблицу:
Установим текущую зону для Москвы (в Москве с недавних пор нет перехода на летнее время, и время UTC+4):
Создадим две записи с летним и зимним временем соответственно:
Посмотрим, что показывает выборка этих дат из базы данных:
Видим, что в обоих колонках значения одинаковые, это происходит потому что функция UNIX_TIMESTAMP рассматривает значение аргумента в текущей зоне и конвертирует его в UTC. Очевидно, что одинаковые значения одинаково сконвертируются в одно и то же значение Mon, 10 Dec 2012 11:08:05 UTC .
Теперь переезжаем в Лондон!
Тут нет ничего удивительного, согласно документации, TIMESTAMP , перед тем как вставиться в базу конвертируется в UTC, поэтому после того как мы сменили текущую зону база данных нам выдает значение этого времени в текущей зоне. Значения типа DATETIME не изменились.
Теперь рассмотрим более детально работу алгоритма для Москвы. Значения для ts при вставке сконвертировались в UTC, и при выборке переводились в значения в соответствии с текущей зоной (как и для Лондона) 15 часов, а при выборе UNIX_TIMESTAMP — они просто отображались как они сохранены в базе.
Теперь уже ожидаемый результат для Лондона:
Значения ts не изменились, а значения dt рассматриваются как значения в текущий зоне, поэтому летнее время (первая запись) 1339337285 = Sun, 10 Jun 2012 14:08:05 GMT , а зимнее время (нижняя запись) 1355152085 = Mon, 10 Dec 2012 15:08:05 GMT .
На всякий случай проверим поведение для UTC.
Все согласно прежнему описанию, значения ts не изменились, значения dt рассматриваются в текущей зоне, поэтому тоже не меняются ( 1339340885 = Sun, 10 Jun 2012 15:08:05 GMT; 1355152085 = Mon, 10 Dec 2012 15:08:05 GMT ).
Вывод:
- При работе с DATETIME и переезде сервера (неправильной настройке временной зоны во время вставки или импорта данных) с потерей информации о времени смены временной зоны сервера/соединения вы потеряете информации о действительном времени событий. Например, мы создали записи в 15 часов по московскому времени (импортировали данные в базу из backup’а), потом настроили наш сервер на UTC и не заметили, что до этого временная зона была московской. В результате вместо 11 часов по UTC оба наших заказа теперь сделаны на 4 часа позже — в 15 часов, а могли бы быть и в другой день. Поэтому на мой взгляд работать надо с TIMESTAMP .
- Так же, чтобы не возникало лишних проблем при отладке на сервере лучше иметь зону UTC, и работать с данными в UTC, а на клиентской части отображайте в той зоне, в которой хочет клиент.
- Так же хороший пример в конце статьиfeedbee.
- Чтобы избежать проблем с leap second так же стоит работать с unix epochs в UTC (см. раздел про Leap second).
SQLite3
Рассмотрим ситуацию с sqlite3. Согласно документации в sqlite нет типа данных для сохранения времени, но есть функции для работы со временем, сохраненным в виде текста, числа с плавающей точкой и в виде целого числа. В целом эти представления принципиально ничем не отличается. Можно считать, что в sqlite текущая временная зона не используется, если вы не используете модификаторы localtime и utc. Например, вне зависимости от настроек системы, CURRENT_TIMESTAMP имеет значение в UTC.
Поэтому конвертируйте свои данные в вашей программе в utc и используйте unix epochs, чтобы не искать ошибки при парсинге строк.
Функции для отладки:
Как пользователь видит время
Если вы работаете с типом datetime и не конвертируете его, то пользователи запутаются во времени. Например, если два пользователя живут в разных временных зонах, то, видя одну и ту же строку времени без указания зоны, они будут думать о разных временах. Чтобы не повторяться, вот ссылка с примером.
С-функции по работе со временем
Во-первых, очень полезно ознакомиться с описанием работы со временем в glibc. Мы же рассмотрим несколько примеров, касающихся результатов работы нескольких функций в разных временных зонах. Оказывается, даже в документации говорится, что struct tm (далее broken-down time) обычно используется только для отображаения пользователям (из-за наглядности), т.е. в вашей программе лучше использовать другие более подходящие типы данных.
Рассмотрим несколько примеров:
Конвертирует simple time в broken-down time, выраженное относительно пользовательской зоны.
| зона в системе | UTC | Europe/Moscow | Europe/London |
|---|---|---|---|
| вывод hour | 11 | 15 | 12 |
| вывод isdst | 0 | 0 | 1 |
| вывод zone | UTC | MSK | BST |
| зона в системе | UTC | Europe/Moscow | Europe/London |
|---|---|---|---|
| вывод hour | 11 | 15 | 11 |
| вывод isdst | 0 | 0 | 0 |
| вывод zone | UTC | MSK | GMT |
Возвращает значение для зоны UTC вне зависимости от зоны пользователя.
| зона в системе | UTC | Europe/Moscow | Europe/London |
|---|---|---|---|
| вывод hour | 11 | 11 | 11 |
| вывод isdst | 0 | 0 | 0 |
| вывод zone | GMT | GMT | GMT |
| зона в системе | UTC | Europe/Moscow | Europe/London |
|---|---|---|---|
| вывод hour | 11 | 11 | 11 |
| вывод isdst | 0 | 0 | 0 |
| вывод zone | GMT | GMT | GMT |
(синоним timelocal, но редко встречается)
Конвертирует broken-down time в simple time.
Внимание: выставляет у аргумента текущую зону.
Поле tm_zone не рассматривается как аргумент, считается, что время задано в текущей временной зоне и возвращается время в UTC.
| зона в системе | UTC | Europe/Moscow | Europe/London |
|---|---|---|---|
| вывод t | 1339326485 (Sun, 10 Jun 2012 11:08:05 GMT) | 1339312085 (Sun, 10 Jun 2012 07:08:05 GMT) | 1339326485 (Sun, 10 Jun 2012 11:08:05 GMT) |
| вывод hour | 11 | 11 | 12 |
| вывод isdst | 0 | 0 | 1 |
| вывод gmtoff | 0 | 14400 (4*60*60) | 3600 (1*60*60) |
| вывод zone | UTC | MSK | BST |
Обратите внимение на то, что поля tm_hour и tm_isdst изменились для Лондона, это часть процесса нормализации полей структуры broken-down time.
теперь для
| зона в системе | UTC | Europe/Moscow | Europe/London |
|---|---|---|---|
| вывод t | 1355137685 (Mon, 10 Dec 2012 11:08:05 GMT) | 1355123285 (Mon, 10 Dec 2012 07:08:05 GMT) | 1355137685 (Mon, 10 Dec 2012 11:08:05 GMT) |
| вывод hour | 11 | 11 | 11 |
| вывод isdst | 0 | 0 | 0 |
| вывод gmtoff | 0 | 14400 (4*60*60) | 0 |
| вывод zone | UTC | MSK | GMT |
Работает в UTC.
| зона в системе | UTC | Europe/Moscow | Europe/London |
|---|---|---|---|
| вывод t | 1339326485 (Sun, 10 Jun 2012 11:08:05 GMT) | 1339326485 (Sun, 10 Jun 2012 11:08:05 GMT) | 1339326485 (Sun, 10 Jun 2012 11:08:05 GMT) |
| вывод hour | 11 | 11 | 11 |
| вывод isdst | 0 | 0 | 0 |
| вывод gmtoff | 0 | 0 | 0 |
| вывод zone | GMT | GMT | GMT |
теперь для
| зона в системе | UTC | Europe/Moscow | Europe/London |
|---|---|---|---|
| вывод t | 1355137685 (Mon, 10 Dec 2012 11:08:05 GMT) | 1355137685 (Mon, 10 Dec 2012 11:08:05 GMT) | 1355137685 (Mon, 10 Dec 2012 11:08:05 GMT) |
| вывод hour | 11 | 11 | 11 |
| вывод isdst | 0 | 0 | 0 |
| вывод gmtoff | 0 | 0 | 0 |
| вывод zone | GMT | GMT | GMT |
Вывод:
Если вы хотите отобразить время пользователю в вашей программе на пользовательском компьютере, то используйте функции timelocal/localtime , если вы работает на сервере, то используйте функции timegm/gmtime . Так же, устанавливайте на сервере зону UTC, на случай, если вдруг кто-то из ваших коллег или в сторонней библиотеке использует *local* функции. Даже на компьюетере пользователя храните и работайте со временем в UTC, так, если он сменит свою зону, все даты останутся правильными.
Примечание
Настройка временных зон в linux
Рассмотрим только deb-based дистрибутивы и пару железных методов по настройке временн`ой зоны.
- Способ первый (работает на deb-based дистрибутивах):
Выполнить в терминале команду и следовать инструкциям (“UTC” находится в разделе “Etc”):
sudo dpkg-reconfigure tzdata - Способ второй (работает, наверное везде):
Выполнить в терминале команду:
и на всякий случай отредактировать /etc/timezone (если он есть)
Установить переменную окружения TZ в нужную зону, например:
Источник
