Конвертер метки времени Unix

секунды эпохи = суток с 1970-01-01 × 86400 + секунд с полуночи UTC; дата и время = та же арифметика, прочитанная назад

mode

Куда идём: введена отметка времени и возвращается дата — или введены дата и время и возвращается отметка

timestamp

Само число, в секундах или в миллисекундах в зависимости от поля единицы. Используется только в направлении «из отметки в дату»

unit

Считает ли введённое число секунды (10 цифр для дат этого века) или миллисекунды (13 цифр). Используется только в направлении «из отметки в дату»

date

Календарный день по UTC, в виде ГГГГ-ММ-ДД. Используется только в направлении «из даты в отметку»

time

Время на часах по UTC, в виде ЧЧ:ММ или ЧЧ:ММ:СС. Используется только в направлении «из даты в отметку»

utcDate

Календарная дата, на которую попадает отметка времени, по UTC. Это главный результат

utcTime

Время на часах по UTC, всегда с секундами. Любая доля секунды во вводе отбрасывается, а не округляется

utcWeekday

День недели, на который попадает эта дата, числом от 0 (воскресенье) до 6 (суббота)

isoDateTime

Полная форма ISO 8601, например 2026-01-15T12:00:00Z, готовая к вставке в код или в журнал

timestampSeconds

Тот же момент целыми секундами с 1970-01-01T00:00:00Z, усечённый, а не округлённый, чтобы никогда не расходиться с показанным выше временем

timestampMilliseconds

Тот же момент в миллисекундах — значение в секундах, умноженное на 1000, с сохранением доли секунды, если она во вводе была

Страница нужна, когда число и дату надо свести друг с другом: прочитать отметку времени из серверного журнала, ответа API или строки базы данных; проверить, в секундах или в миллисекундах пришло присланное значение; или получить отметку времени для хранения. Страница намеренно останавливается на UTC. Она не переводит в ваше местное время и не спрашивает, в какой зоне вы находитесь: у метки времени Unix зоны нет, поэтому честный ответ — ответ по UTC, а превратить его в местное показание часов — работа калькулятора часовых поясов. Арифметику над отметками она тоже не делает: для вопроса «а что будет через тридцать дней» сначала переведите значение, а потом возьмите калькулятор дат.

1. 1768478400 — опорный момент

   1. Число задано в секундах, поэтому это уже значение эпохи — до чтения ничего переводить не нужно
   2. Деление на 86400 даёт число целых суток с 1 января 1970 года, а остаток — время суток: результат попадает на 15 января 2026 года, 12:00:00 UTC
   3. 15 января 2026 года — четверг, поэтому номер дня недели равен 4
   4. В полной записи это 2026-01-15T12:00:00Z — та форма, которой ждёт журнал или API
   5. Строка миллисекунд — тот же момент, умноженный на 1000: так выглядит то же значение, когда система сообщает его в миллисекундах

   Это то значение, на котором страница открывается, и его стоит запомнить как опорное: 1768478400 — это полдень UTC 15 января 2026 года. Любой другой перевод на этой странице легче проверять на здравый смысл, когда одна отметка уже привычна: неверный ответ обычно ошибается на целые сутки или в 1000 раз, а и то и другое сразу видно рядом со знакомым ориентиром.

2. 2147483647 — последняя секунда 32-битной эпохи

   1. 2147483647 — это 2 в степени 31 минус 1: наибольшее число, которое вмещает знаковое 32-битное целое
   2. Прочитанное как число секунд эпохи, оно даёт 19 января 2038 года, 03:14:07 UTC, — в этом и состоит проблема 2038 года: система, хранящая отметку в таком типе, исчерпывает место на следующей же секунде и переносится на дату 1901 года
   3. 19 января 2038 года — вторник, день недели 2
   4. Строка секунд возвращает число без изменений — это и есть проверка, что значение прошло туда и обратно через одну и ту же арифметику

   Это строка из таблицы ниже, пропущенная через калькулятор. Проблема 2038 года не в том, что дата недостижима — эта страница берёт её без всяких возражений, — а в том, что программа со знаковым 32-битным счётчиком не может представить следующую секунду. У 64-битных счётчиков такого края нет ни на каком обозримом горизонте, поэтому то же значение в миллисекундах равно 2147483647000.

3. Значение в миллисекундах с долей: 1768478400500

   1. В числе 13 цифр и единица указана как миллисекунды, поэтому это тот же момент, что и в первом примере, плюс полсекунды
   2. Время на часах отбрасывает долю, а не округляет её, поэтому читается 12:00:00, а не 12:00:01
   3. Строка секунд усекается так же: 1768478400, а не 1768478401
   4. Строка миллисекунд долю сохраняет, потому что это единственное место, где она есть в результате

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

4. Обратное направление: 15 января 2026 года, 12:00:30 UTC

   1. Дата превращается в число суток с 1 января 1970 года и умножается на 86400 — так получаются секунды до полуночи
   2. К ним прибавляются тридцать секунд после полуночи: итог равен 1768478430, то есть значение из первого примера плюс 30
   3. Поле времени принимает секунды, поэтому 12:00:30 читается точно, а не округляется вниз до минуты
   4. Строки даты и дня недели возвращаются без изменений, потому что перевод туда и обратно — тождественная операция

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

Всё, что сообщает страница, дано по UTC, и в местный часовой пояс она не переводит никогда: метка времени Unix определена без зоны, поэтому превращением её в местное показание часов занимается калькулятор часовых поясов. Окно — с 1970-01-01T00:00:00Z по 2100-12-31T23:59:59Z, и значения вне него отклоняются, а не считаются молча: отрицательные отметки — законные метки времени Unix для дат до начала отсчёта, но страница говорит об этом и останавливается вместо того, чтобы выдать ответ про 1969 год, противоречащий её же заявленному диапазону. Доли секунды усекаются, а не округляются, поэтому значение в миллисекундах не теряет своей точности, но и не влияет на показанные секунды. Строки с датами в других форматах страница не разбирает, отметку времени вашей машины не читает и арифметики не делает: для даты через тридцать дней от переведённого значения возьмите калькулятор дат.

Что такое эпоха Unix?

Эпоха Unix — это количество секунд, прошедших с 1970-01-01T00:00:00 UTC, то есть с нулевой точки, от которой считают системы Unix. Это же называют временем Unix или временем POSIX. От вашего местоположения здесь не зависит ничего: эпоха Unix определена по UTC, поэтому один и тот же момент имеет во всём мире одно и то же значение, и две машины в разных зонах, расходящиеся в показаниях местных часов, всё равно сойдутся в отметке времени.

Как перевести отметку времени в дату?

Введите значение, укажите, считает ли оно секунды или миллисекунды, и прочитайте полученные дату и время. Первое, что стоит проверить, — число цифр: отсчёт секунд для даты этого века содержит 10 цифр, а отсчёт миллисекунд — 13. Значение из 13 цифр, прочитанное как секунды, попадает на десятки тысяч лет вперёд и отклоняется; значение из 10 цифр, прочитанное как миллисекунды, попадает в январь 1970 года, и это та ошибка, которая о себе не объявляет. Быстрее всего подтверждает результат обратный перевод в другую сторону.

Что такое проблема 2038 года?

Проблема 2038 года — это то, что происходит, когда система хранит отметку времени в знаковом 32-битном целом: наибольшее значение такого типа равно 2147483647, то есть 2038-01-19T03:14:07 UTC, и секундой позже счётчик переполняется на дату 1901 года. Это ограничение хранения, а не самой отметки времени, и у 64-битных счётчиков его нет. Эта страница переводит и это значение, и всё, что за ним, без всяких затруднений, потому что работает с двойной точностью, а не с 32-битными целыми.

Что хранить — секунды или миллисекунды?

Обе формы широко используются, и ни одна не ошибочна, но само по себе значение не говорит, какая это из них, поэтому единица должна ехать вместе с числом или быть оговорена заранее. Миллисекунды сохраняют доли секунды и используются объектом Date в JavaScript и многими системами журналирования; секунды определены в POSIX и возвращаются большинством API и баз данных. Перевод между ними — это умножение на 1000, и страница печатает обе строки, чтобы пара была видна с одного взгляда.

Формат ISO 8601 — это то же самое, что метка времени?

Нет, и их легко спутать, потому что оба описывают один и тот же момент. ISO 8601 — это письменная форма, 2026-01-15T12:00:00Z, читаемая человеком, сортируемая и однозначная насчёт смещения UTC благодаря завершающей Z. Метка времени Unix — одно число без всякого форматирования. Строку ISO 8601 вставляют в документ или в URL, а число хранят и сравнивают. Страница печатает обе из одного перевода, поэтому их можно сверить друг с другом.

• The Open Group Base Specifications — Seconds Since the Epoch — The Open Group — the normative definition of the epoch and of leap-second handling
• RFC 3339 — Date and Time on the Internet: Timestamps — IETF — the format of the Z-suffixed string this page prints
• MDN — Date — MDN Web Docs — the millisecond count and its range in JavaScript