Epoch time что это

Unix time конвертер (Конвертер времени Unix онлайн)

UNIX-время или POSIX-время (англ. Unix time) — способ кодирования времени, принятый в UNIX и других POSIX-совместимых операционных системах.
Моментом начала отсчёта считается полночь (по UTC) с 31 декабря 1969 года на 1 января 1970, время с этого момента называют «эрой UNIX» (англ. Unix Epoch).
Время UNIX согласуется с UTC, в частности, при объявлении високосных секунд UTC соответствующие номера секунд повторяются.
Способ хранения времени в виде количества секунд очень удобно использовать при сравнении дат (с точностью до секунды), а также для хранения дат: при необходимости их можно преобразовать в любой удобочитаемый формат. Дата и время в этом формате также занимают очень мало места (4 или 8 байтов, в зависимости от размера машинного слова), поэтому его разумно использовать для хранения больших объёмов дат. Недостатки в производительности могут проявиться при очень частом обращении к элементам даты, вроде номера месяца и т. п. Но в большинстве случаев эффективнее хранить время в виде одной величины, а не набора полей.

Конвертивание эпохи Unix в человекопонятную дату(human readable date)

Unix дата начала и конца года, месяца или дня

Перевод секунд в дни, часы и минуты

Как получить Unix время в.

Конвертирование даты в Unix время в.

Конвертирование Unix времеми в понятную дату(human readable date).

Для чего нужен инструмент «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 конвертер» такая конвертация займет у вас доли секунды.

Epoch Time

Unix-время (англ. Unix time, также POSIX-время) — система описания моментов во времени, принятая в Unix и других POSIX-совместимых операционных системах.

Определяется как количество секунд, прошедших с полуночи (00:00:00 UTC) 1 января 1970 года (четверг); этот момент называют «эпохой Unix» (англ. Unix Epoch).

Целочисленное представление

Unix-время представлено целым числом, которое увеличивается с каждой прошедшей секундой без необходимости вычислений для определения года, месяца, дня, часа или минуты для удобства восприятия человеком.

Современное Unix-время согласуется с UTC — отсчет происходит в секундах СИ. Временной промежуток одного дня почти всегда разбит на 86 400 секунд, но при объявлении дополнительных секунд составляет 86 401 секунду. Такие секунды, согласно Всемирному времени, сохраняют длительность дней синхронизированной со временем оборота планеты. В Unix-времени соответствующие номера секунд повторяются, то есть високосные секунды не учитываются.

В момент времени 00:00:00 UTC 1 января 1970 года (четверг) Unix-время равно нулю. Начиная с этого времени, число возрастает на определённое количество в день. Таким образом, к примеру, 16 сентября 2004 года в 00:00:00, спустя 12677 дней после начала отсчета Unix-времени, время будет представлено числом

12 677 × 86 400 = 1 095 292 800

Или в случае с 17 декабря 2003 года в 00:00:00, через 12403 дня после начала отсчёта время будет являться числом

12403 × 86 400 = 1 071 619 200

Расчеты могут быть также произведены в обратном направлении используя отрицательные числа. К примеру, дата 4 октября 1957 года 00:00:00, а это 4472 дня до начала отсчета, представлена в Unix-времени числом

−4472 × 86 400 = −386 380 800

Каждый день число, представляющее Unix-время, вычисляется описанным образом в UTC (00:00:00Z), и увеличивается ровно на 1 в секунду, начиная с полночи. Следовательно, момент времени 16-09-2004 17:55:43,54, соответствующий 64 543,54 секунды от полуночи этой даты, из примера выше, будет представлен в Unix-времени числом

1 095 292 800 + 64 543,54 = 1 095 357 343,54

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

Используемую целочисленную систему удобно использовать для сравнения и хранения дат (дата и время в этом формате занимают всего 4 или 8 байт). При необходимости обращения к элементам дат (день, месяц, год) секунды можно преобразовать в любой подходящий формат (и наоборот).

В программах для хранения Unix-времени используется целочисленный знаковый тип. 32-битные числа со знаком могут ссылаться на моменты времени от пятницы 13 декабря 1901 года 20:45:52 до вторника 19 января 2038 года 03:14:07 включительно.

Чтобы узнать текущее Unix-время в большинстве Unix-подобных систем, можно использовать команду

What is the Epoch Time?

In computer science, the epoch time, also known as Unix time, is considered the number of seconds since 1 January 1970. In other words, it is the number of seconds counted since that day.

The epoch time is the same for every country regardless of where you stay in the globe. The epoch time is measured in seconds.

The epoch refers to the instance of time. Thus, epoch time refers to the number of seconds from the zero point or epoch time.
Epoch time is purely used for efficiency reasons as it takes less space to represent a single number in seconds rather than storing in words like year, month, hour etc.

What Is Epoch Time With Regards To Computer Science

To measure height, weight or anything, you need an initial value. For example, you need to have an initial value to measure the height. The initial value to measure height is 0cm or 0m. you cant start to measure the height from negative values. 0 is considered as the default standard when it comes to measuring weight and height. The same theory applies to computers; The computer needs to know where to begin tracking the time. The epoch time is considered as one the most popular convention for computers to track time. The epoch starts at 00:00:00 Thursday 01 January 1970, UTC. Epoch time is completely measured in seconds. It is also known as the number of seconds since epoch 0

Why Epoch Is Necessary ?

A computer requires an initial value to add some seconds on top of it. Adding some value to an unspecified point in time wouldn’t make any sense. To give an initial zero point, the epoch time has been added.

Computers can only interrupt binary codes, also known as 1s and 0s. Therefore, scientists came up with a solution to help computers understand date by simply providing it in seconds(numeric values). These seconds were calculated by simply picking a reference point and counting the number of seconds since that reference point, known as epoch time.

Why Does Unix Epoch Time Start at 1970

During 1970 and 1971, the Unix Systems were developed, and around 1971 they released the initial or the first internal manual.

Dennis Ritchie and Ken Thompson were the people to develop the Unix Systems, and they decided to set the first epoch on 01/01/1971.

Around 1971 the Unix development team set the first epoch on 01/01/1971. The Unix development team wanted to decide a recent epoch time and date as there zero point since the earliest versions of Unix 32 bit systems were only able to represent in a short time span with less than 850 days. This issue occurred because the Unix 32 bit systems measured time in 1/60th seconds intervals.

Later on, Unix System started to measure the time in 1-second intervals; thus, the time span has been able to increase from 829 days to 136 years. Due to this fact, the epoch was no longer needed to be one of the recent.

After a while, the epoch was once again changed to 01/01/1970. Which was the beginning of the decade, and this change was done for many convenient reasons

You can view your current Epoch time and do the necessary calculations here.

Problems with Unix Epoch Time

As of now, the epoch time is a very big number since many computers operate on 32 bits. Epoch time is almost going to pass the number that 32 bit systems can understand. It is expected that around January 19th 2038, the epoch time will surpass the maximum number that a 32-bit system can understand. Any software using 32-bit timestamps needs to be updated to a new convention to solve this. One way to do this is by migrating the 32-bit system into a 64 bit one. If the necessary updation is not done before the time exceeds the limited number, it will be falsely interpreted as FRIDAY 13 DEC 1901 UTC, and this problem is known as the Year 2038 problem in computer science.

Conclusion

The computer requires an initial value or the base so that the computer can add seconds on top of it. If the computer adds seconds on top of an unspecified value, it doesn’t make sense. Therefore, epoch time, also known as zero time, is considered the base. January 1st 1970, is considered as the epoch time by Unix systems and Dennis Ritchie and Ken Thompson made this decision.

Время — иллюзия, время Unix — иллюзия вдвойне…

Как вы хорошо знаете, в Unix-системах мы измеряем время как количество секунд, прошедших с «эпохи»: 00:00:00 UTC 1 января 1970 года. Немало людей сильно разозлилось из-за этого, да и вообще, общественное мнение сочло это ошибкой.

Во-первых, это определение основано не на чём-то разумном, например, на объективной частоте колебаний атома цезия-133, а на удобной доле времени полного оборота одного большого камня вокруг собственной оси.

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

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

Как же мы к этому пришли? Всё началось в 1971 году, когда в в первом издании руководства для программиста Unix было дано определение времени Unix как «времени с 00:00:00 1 января 1971 года, измеряемого в шестидесятых долях секунды«:

Именно так, изначально эпохой Unix было 1971-01-01T00:00:00 . Вы спросите, какого часового пояса? Ну, это точно не был «UTC», потому что он заменит GMT в качестве стандартного времени только в 1972 году. Во-вторых, обратите внимание, что время измерялось в 1/60 секунды, а не в секундах. Зачем же так сделали?

Вспомним, что в то время Unix разрабатывался в США на PDP-11. Эти системы имели часы линейного времени (Line-Time Clock, LTC), использующие частоту питания переменного тока для генерации прерывания для процессора. Тогда это прерывание использовалось для обновления системных часов.

Забавно здесь то, что эта частота прерываний зависит от частоты в сети источника питания. В основной части Азии и Европы эта частота равна 50 Гц, однако в США Westinghouse Electric Corporation (конкурент Томаса Эдисона и General Electric; любопытный факт: позже Westinghouse приобрела CBS, а затем была куплена Viacom) заметила, что использовавшиеся тогда дуговые лампы с угольным электродом меньше мерцают при 60 Гц, а поэтому стандартизировала эту частоту.

(Странный побочный эффект этого различия между США и Европой заключается в том, что в Японии используются обе частоты: на западе, где первые генераторы были куплены у немецкой AEG и установлены в Токио, частота в сети равна 50 Гц; на востоке, в Осаке, были установлены генераторы G.E., и используются 60 Гц. В результате этого в стране теперь работает множество высоковольтных линий постоянного тока для преобразования электричества между двумя регионами!)

Электросеть Японии

Итак, в первом издании UNIX измерял время на этих 60 Гц с хранением в 32-битных integer, таким образом имея возможность учитывать только 2^32 / 60 тактов/с * 60 с/мин * 60 мин/ч * 24 ч/д * 365 д/г = 2,3 лет , как и написано в руководстве. Несколько позже в том же 1971 году измерению времени было дано другое определение, оно учитывалось в секундах и могло описывать до 136 лет. Датой же эпохи Unix был достаточно произвольно выбран 1970 год (вопреки распространённому заблуждению о том, что она обозначает дату рождения Unix):

«В то время у нас не было плёночных накопителей, работала пара файловых систем, и мы постоянно меняли начало отсчёта времени. Поэтому в конце концов мы сказали: давайте выберем что-то одно, что достаточно долго не будет переполняться. Нас вполне устроил 1970 год», — сказал он.

(Истинная дата рождения Unix приходится примерно на 1969 год, когда Кен Томпсон портировал «Space Travel» на PDP-7, поэтому легко понять, почему эпоха Unix кажется обозначением рождения Unix.)

Секунды координации

Итак, теперь у нас есть 32-битный счётчик секунд от эпохи, который равномерно увеличивает значение с частотой 1 Гц и гарантирует нам, что будет насчитывать ровно 86400 секунд в любой 24-часовой период. Однако наш космический булыжник отсчёта замедляется в своём вращении, поэтому время от времени это число нужно изменять.

Для этого Международная служба вращения земли (IERS) отправляет всем Повелителям Времени электронные письма, сообщающие, должна или нет добавляться секунда координации:

Сегодня мы не можем винить время эпохи Unix за то, что оно изначально не учитывало секунды координации, потому что их не существовало до 1972 года. С тех пор (на 2022 год) произошло уже 27 положительных секунд координации, последняя из которых была введена в конце 2016 года. Каждый раз, когда происходит секунда координации, время эпохи Unix просто притворяется, что этого не было, из-за чего две даты соответствуют одной метке времени эпохи (epoch-time.c):

(И давайте не забывать обо всех отрицательных секундах координации и тот факт, что некоторые системы Unix определяют диапазон tm_sec как [0-61] , учитывая мифическую «двойную секунду координации», которой на самом деле никогда не существовало.)

Хорошо в этом то, что всё это соответствует требованиям POSIX:

Значение, которое аппроксимирует количество секунд, прошедшее после эпохи.

Соотношение между истинным временем суток и текущим значением секунд после эпохи точно не установлено.

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

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

Даже при равномерном отсчёте и игнорировании секунд координации используемый для измерения секунд после эпохи тип данных time_t неизбежно придёт к переполнению. Хорошо, что есть стандарты, которые спасут нас в этой ситуации! Пусть POSIX не решает проблемы, но хорошо в стандартах то, что их много и можно выбрать подходящий, не так ли? Ох, постойте, в чём же дело? Давайте разберёмся.

Плохие новости: стандарты нас не спасут. Например, стандарт C гласит:

Что ж, ладно. Имея 32-битный time_t , мы можем рассчитывать начиная с 1970 года примерно на 136 лет. Однако time_t является знаковым 32-битным integer, то есть у нас есть всего 68 лет в обоих направлениях, из-за чего возникает так называемая «Проблема 2038 года».

Она состоит в том, что самая большая дата, которую можно записать как time_t при помощи знакового 32-битного integer — это 2^31 — 1 = 2147483647 эпохи, или 2038-01-19T03:14:07Z:

Это легко исправить, правда? Мы «просто» изменяем тип данных time_t на знаковый 64-битный integer, что даёт нам теоретический максимум даты эпохи 2^63-1 = 9223372036854775807 после 1 января 1970 года. Как любят говорить люди, это значение задаёт дату примерно на 292 миллиарда лет в будущем, или примерно в 22 раз больше приблизительного возраста Вселенной, поэтому официально может считаться Чьей-то Чужой Проблемой.

Но — всегда есть «но», не правда ли? — действительно ли это произойдёт? Почему бы не попробовать и не проверить, как разные системы поведут себя, если мы передадим им для обработки не совсем логичные значения времени?

Оборот mktime(3)

Хотя время представлено в виде time_t , используется и другой популярный формат для записи разбитого на части времени — struct tm , из которого можно получить time_t , вызвав mktime(3) . В POSIX зафиксированы следующие элементы struct tm :

Забавно в описанных здесь диапазонах то, что они в лучшем случае являются… рекомендательными. В POSIX конкретно написано:

Так что же произойдёт, если передать mktime(2) тип struct tm со значениями вне этих диапазонов? Рассмотрим следующую программу:

Здесь перед присвоением tm_sec значения наш struct tm задавал дату December 31st, 22:57:00, 2022. Но потом мы присвоили tm_sec значение 3785 , то есть 1 час, 3 минуты и 5 секунд. Это приводит к тому, что выполняется инкремент tm_min на 3 минуты, что приводит к увеличению tm_hour на единицу. Затем мы ещё раз выполняем инкремент tm_hour (из оставшихся от tm_sec 3600 секунд), что приводит к оборачиванию этого значения на 00 и необходимости инкремента tm_mday . Теперь tm_mday оборачивается до 01 с инкрементом tm_year , и в результате мы получаем дату 2023-01-01T00:00:05 .

Такая нормализация меток времени становится ещё более запутанной, когда мы добавляем отрицательные значения (например, tm_mday = -1 означает предыдущий день tm_mon — 1 ) или (снова) при участии секунд координации, что может стать причиной головной боли. Лучше избегать такой ситуации.

Забавная date(1)

Давайте рассмотрим даты эпохи в момент или рядом с эпохой. Проигнорируем тот факт, что время эпохи до 1972 года определено не очень чётко, поскольку время эпохи по определению считается в UTC, но (см. выше) UTC стандартизировали только в 1972 году. Ну, мы поступим точно так же, как Unix поступает с секундами координации, и притворимся, что это нас не волнует.

Отобразить произвольную дату при помощи команды date(1) довольно легко. Достаточно просто передать дату в формате CCyymmddHHMM.SS . Если только вы не работаете в Linux, где date(1) GNU хочет использовать, наверное, самый выбешивающий формат ( MMDDhhmmCCYY.ss ). Зачем вставлять год между минутами и секундами?

Однако использование любого из этих форматов всё равно бесполезно для наших целей, потому что в определённый момент нам нужно будет выйти за пределы годов из четырёх цифр, поэтому давайте укажем непосредственно секунды после эпохи (» -r <seconds> » для date(1) в BSD, » —date @<seconds> » для date(1) в GNU).

Отобразить даты в момент эпохи или рядом с ней довольно просто:

( date(1) GNU, использующая AM/PM вместо 24 часов, раздражает, ну да ладно.)

Давайте посмотрим, что произойдёт, если мы попробуем проверить 32-битный time_t . Как говорилось выше, проблема 2038 года возникнет в 2147483648 / -2147483649 эпохи:

О, постойте-ка. Похоже, у OmniOS возникают проблемы с датами эпохи после 2^31. Интересно, что произойдёт, если мы не только отобразим дату, но и установим её? Давайте в цикле установим дату и выведем её:

Замечательно. Обратите внимание, что дата на самом деле оборачивается, но ОС сходит с ума. Но ведь у других систем не должно быть никаких проблем с установкой даты, правильно?

Вот так, в NetBSD мы не можем установить дату до эпохи, а в Linux (с версии ядра 4.3) мы не можем установить дату до текущего аптайма. settimeofday(2) вернёт EINVAL из-за гарантий, даваемых его » CLOCK_MONOTONIC «, который, согласно POSIX, «представляет количество времени после неуказанной точки в прошлом«:

С учётом всего этого, похоже, OmniOS вычисляет аптайм на основе времени запуска относительно системной даты, а, например, NetBSD и Linux хранят отдельные счётчики:

Попытка установить дату до эпохи тоже приводит к разным результатам. В NetBSD и Linux это сделать просто не удастся, а в OmniOS будет установлен месяц, день, час, минута и секунда, однако год будет ограничен значением 1970:

Но какую максимальную дату мы можем установить в системах, использующих 64-битный time_t ? Как говорилось выше, можно ожидать, что доступно время до 2^63 — 1 = 9223372036854775807 эпохи. Давайте сначала отобразим дату, а затем попытаемся её установить:

Это интересно. Несмотря на то, что нам обещали 64-битный time_t , мы не можем установить время на 9223372036854775807 . Похоже, максимальное значение равно 67768036191676799 в 2147485547 году. Хотя поначалу это значение кажется произвольным, можно заметить, что 2147485547 — это 2^31 — 1 , и внезапно всё обретает смысл: даже несмотря на то, что time_t является 64-битным, tm_year структуры struct tm всё равно остаётся 32-битным, а потому максимальным значением, которое он может задать, является последняя секунда 2147485547 года.

А как дела в FreeBSD? Почему в ней время 67768036191676799 эпохи является недопустимым, а 67767976233532799 эпохи соответствует тому, что на других платформах является 67768036191676799 ? Если провести вычисления, то можно заметить, что разница между этими двумя моментами времени эпохи равна 1900 годам, то есть, очевидно, FreeBSD основывает свой tm_year не на 1900 годе (как заявляется struct tm в <time.h> ), а на 0 годе? Так как я не смог с этим разобраться, то отправил баг-репорт.

Если мы попытаемся установить дату, то поначалу заметим, что при использовании date(1) NetBSD невозможно установить дату выше 9999 года (ещё один баг-репорт), но забавно, что на самом деле это не важно, поскольку мы всё равно не можем добраться выше 4147 года:

Так получилось потому, что в NetBSD есть жёстко прописанное ограничение в 2^36 = 68719476736 для значения tv_sec , которое принимается при установке времени, потому что бОльшие значения вызывают недовольство KUBSAN (код):

В Linux используется другой практический максимум даты, установленный на 2232 год:

Причина этого ограничения, найденная в исходном коде, заключается в том, что оно может использовать 30-летний аптайм до оборачивания счётчика:

Это означает, что в Linux знаковое 64-битное максимальное значение времени ( 2^63 — 1 = 9223372036854775807 ) не обозначает секунды после эпохи, а подсчитывает наносекунды после эпохи, поэтому теоретическая максимальная дата Linux ( KTIME_SEC_MAX ) снижается до всего лишь 9223372036 секунд эпохи, или даты 2262-04-23T11:47:16, что очень далеко от «22 приблизительных возрастов Вселенной», и ближе к тому, чтобы стать реальной проблемой.

Проверяя, какое значение FreeBSD позволяет установить для часов, я выяснил, что в двух последних релизах это значение различается, но оба релиза имели неприятную проблему, приводящую к спонтанной перезагрузке системы:

Примечание: изначально я могу установить дате значение больше 49282253052249598 , но спустя примерно три секунды система перезагружается. Если задать дату на одну секунду меньше, то есть 49282253052249597 , то система не перезагружается, даже когда системное время уходит дальше следующего значения. Разве компьютеры — это не чудесно?

О, и ещё кое-что.

Всем нам нравится, что macOS — это UNIX; она является одной из всего шести зарегистрированных на данный момент систем (остальные — это AIX, EulerOS (коммерческий дистрибутив Linux, созданный Huawei), HP-UX, Xinuos (ранее UnixWare, создан старыми AT&T Unix System Laboratories + Novell, SCO,
Caldera и UnXis) и z/OS). Однако фреймворк Core Foundation компании Apple не использует эпоху Unix как основу своего времени. В качестве его даты отсчёта используется 2001-01-01T00:00:00 GMT:

То есть если вы захотите преобразовать эти метки времени в эпоху Unix, нужно будет прибавить 978307200 .

Как я и сказал, время — иллюзия, а время Unix — иллюзия вдвойне. И хотя вас может и не беспокоить проблема 2038 года (наверно, только если вы не пользуетесь OmniOS), возможно, мне удалось показать, что внутри может таиться множество других сюрпризов. А ведь мы ещё не касались безумия, творящегося с часовыми поясами и летним временем…