Конвертер Unix timestamp и epoch — multi-precision

Преобразование Unix timestamp в дату мгновенно. Автоопределение секунд, миллисекунд и микросекунд. Живые часы, двунаправленно. Бесплатно и приватно.

Без отслеживания Работает в браузере Бесплатно

Вся обработка идёт в вашем браузере. Данные не отправляются на сервер.

Текущий Unix timestamp

Unix timestamp

Краткая справка

Примеры кода

Проверено на соответствие POSIX и точность определения precision — Команда инженеров Go-Tools · Mar 22, 2026

Что такое Unix timestamp (epoch time)?

Unix timestamp (также epoch time или POSIX time) — это количество секунд, прошедших с 1 января 1970 года 00:00:00 UTC. Он служит универсальной точкой отсчёта для практически всех вычислительных систем. От ядер Linux и SQL-БД до движков JavaScript и мобильных ОС — практически каждая современная платформа хранит и обменивается временем как Unix timestamp.

Как формально определяет IEEE Std 1003.1 (POSIX): «Unix epoch (1 января 1970, 00:00:00 UTC) служит нулевой точкой POSIX-времени» — конвенция настолько универсально принята, что теперь де-факто стандарт машинно-читаемых timestamp по всему миру. Unix timestamp используют подавляющее большинство серверных систем, БД и сетевых протоколов, включая HTTP-заголовки, JWT-токены и практически каждый REST API.

Сам Unix epoch — 1 января 1970 — выбран не случайно. Unix разработан в Bell Labs в конце 1960-х, и 1970 был удобной круглой стартовой точкой, достаточно недавней для представления всех релевантных дат целыми числами разумного размера. Любой момент времени можно выразить как знаковое 64-битное целое количество секунд от этой опорной точки. Даты до epoch — отрицательные числа: 31 декабря 1969 в полночь UTC = -86400 (один день, или 86 400 секунд, до epoch).

Современные системы часто требуют более тонкого разрешения. Для этого timestamp выражают в миллисекундах (тысячные секунды, как у JavaScript Date.now() или Java System.currentTimeMillis()) или микросекундах (миллионные, в БД вроде PostgreSQL и в high-frequency trading). Точность определяется числом цифр: 10 — секунды, 13 — миллисекунды, 16 — микросекунды. Этот конвертер автоматически определяет точность ввода.

Unix timestamp — основа распределённых вычислений: они независимы от часового пояса, монотонно возрастают (в обычных условиях) и тривиально сортируются как целые числа. Хранение времени как timestamp с конвертацией в человекочитаемый формат только при отображении — лучшая практика, исключающая целые классы багов с часовыми поясами. Компромисс — читаемость: сырой timestamp вроде 1741965432 непрозрачен без конвертера — что и даёт этот инструмент.

Все конвертации идут в браузере через JavaScript Date API — никакие timestamp, даты или другие данные не отправляются на сервер.

Timestamp тесно связаны с другими инструментами разработчика. UUID v1 и v7 встраивают timestamp прямо в идентификаторы, а ответы API с timestamp удобно изучать через форматировщик JSON. Подробное руководство о точности, часовых поясах и ловушках DST с примерами кода на JavaScript, Python и Go — в нашей статье «Полное руководство по Unix timestamp».

// Get the current Unix timestamp in JavaScript
const timestampSeconds = Math.floor(Date.now() / 1000);
console.log(timestampSeconds); // → 1741965432

// Milliseconds (native JavaScript)
const timestampMs = Date.now();
console.log(timestampMs); // → 1741965432000

// Convert timestamp back to a Date object
const date = new Date(timestampSeconds * 1000);
console.log(date.toISOString()); // → '2025-03-14T15:37:12.000Z'

// Python equivalent
// import time
// timestamp = int(time.time())  # → 1741965432

Ключевые возможности

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

Автоматически определяет, в секундах ли (10 цифр), миллисекундах (13) или микросекундах (16) ваш timestamp — без ручного переключения режимов.

Двунаправленная конвертация

Конвертируйте timestamp в человекочитаемые даты или выбирайте дату и время, чтобы мгновенно получить Unix timestamp во всех трёх форматах точности.

Живые epoch-часы

Текущий Unix timestamp тикает в реальном времени — всегда актуальная точка отсчёта для конвертаций и расчётов.

Multi-format вывод

Каждая конвертация одновременно даёт UTC, локальный пояс, ISO 8601 и человекочитаемое относительное время («3 дня назад»).

100% обработка в браузере

Все конвертации в браузере через JavaScript Date API. Никакие timestamp, даты или личные данные не передаются на сервер.

Unix timestamp и другие форматы дат

ISO 8601

2025-03-14T15:37:12Z

И человекочитаемый, и лексикографически сортируемый. Стандарт для обмена данными и API. Предпочтительнее Unix timestamp, когда важна читаемость.

RFC 2822

Fri, 14 Mar 2025 15:37:12 +0000

Человекочитаемый, но не сортируемый. В основном — заголовки email (поле Date). Менее компактен, чем ISO 8601 и Unix timestamp.

Человеческая дата

14 марта 2025, 15:37

Самый читаемый для конечных пользователей формат, но не сортируемый и непригоден для программного использования. Лучше оставить для UI-слоя.

Примеры конвертации

Стандартный Unix timestamp (секунды)

1741965432

2025-03-14T15:37:12Z

10-значный timestamp в секундах — самый частый формат в Unix/Linux, JWT-токенах и логах сервера. Соответствует Pi Day 2025, 15:37:12 UTC.

Y2K timestamp — 1 января 2000

946684800

2000-01-01T00:00:00Z

Unix timestamp для момента Y2K: ровно 946 684 800 секунд после epoch. Полезное значение для калибровки — если конвертер показывает 1 января 2000 для этого ввода, он работает корректно.

Отрицательный timestamp (до epoch)

-86400

1969-12-31T00:00:00Z

Отрицательные Unix timestamp представляют даты до 1 января 1970. Значение -86400 — ровно один день (86 400 секунд) до epoch — это 31 декабря 1969 в полночь UTC. Не все системы поддерживают отрицательные timestamp, но этот конвертер их обрабатывает.

Timestamp в миллисекундах (13 цифр)

1741965432000

2025-03-14T15:37:12.000Z

13-значный timestamp в миллисекундах — нативный формат JavaScript Date.now(), Java System.currentTimeMillis() и большинства современных REST API. Это первый пример, умноженный на 1000. Автодетектор узнаёт длину 13 цифр и разбирает как миллисекунды.

Как конвертировать Unix timestamp в дату

1

Выберите направление

Выберите «Timestamp → Дата», чтобы декодировать Unix timestamp в человекочитаемую дату, или «Дата → Timestamp» — для обратной конвертации.
2

Введите значение

Вставьте или введите Unix timestamp (например, 1741965432 или 1741965432000) в поле ввода. Инструмент автоматически определит секунды, миллисекунды или микросекунды. Для «Дата → Timestamp» выберите год, месяц, день, час, минуту и секунду в date picker.
3

Скопируйте результат

Мгновенно увидите результат в UTC, локальном времени, ISO 8601 и относительном времени. Нажмите «Скопировать» рядом с любым форматом.

Типичные сценарии

Разработка и отладка API: Декодирование непрозрачных timestamp в ответах API, payload JWT (claims iat, exp, nbf), данных webhook и записях логов. Мгновенная проверка истечения токена аутентификации или времени события.
Хранение и запросы timestamp в БД: Конвертация между Unix timestamp и человекочитаемыми датами при написании запросов БД, изучении хранимых записей или валидации, что фильтры по диапазону дат корректно заданы в WHERE.
Анализ и корреляция логов: Многие системные и прикладные логи записывают события как Unix timestamp. Конвертируйте подозрительные записи в человекочитаемое время для корреляции событий между сервисами, идентификации окон атаки или точного определения момента ошибки.
Проверка истечения JWT: JWT кодируют iat (issued at), exp (expires at) и nbf (not before) как Unix timestamp в payload. Вставляйте значения сюда, чтобы проверить окна валидности без ручной epoch-математики.
Планирование cron: Проверяйте, что расписания cron, задачи и time-based триггеры выровнены с задуманными окнами выполнения, конвертируя предложенные времена запуска в timestamp и обратно.
Координация дат между поясами: Unix timestamp inherently timezone-нейтральны. Используйте конвертер для общей точки отсчёта при координации дат и дедлайнов между командами в разных поясах, подтверждая UTC-эквивалент любого локального времени.

Техническая справка

Определение Unix timestamp: Unix timestamp — целое число секунд, прошедших с Unix epoch: 1 января 1970, 00:00:00 UTC. Значение одинаково независимо от локального часового пояса наблюдателя — идеально для timezone-нейтрального хранения и сравнения времени.
Максимум 32-битного знакового целого: Максимум 32-битного знакового целого — 2 147 483 647. Как Unix timestamp это соответствует 19 января 2038 в 03:14:07 UTC. Системы, хранящие timestamp в 32-битных знаковых, переполнятся в этот момент — известно как проблема 2038 года. 64-битные системы могут представлять даты на миллиарды лет вперёд.
JavaScript использует миллисекунды: JavaScript Date.now() и new Date().getTime() возвращают миллисекунды с epoch — не секунды. Это даёт 13-значные числа. Чтобы получить стандартный timestamp в секундах, делите на 1000 и floor: Math.floor(Date.now() / 1000). Многие API ожидают секунды, поэтому эта конвертация критична.
Отрицательные timestamp = даты до epoch: Unix timestamp могут быть отрицательными для дат до 1 января 1970. Например, -86400 = 31 декабря 1969 в 00:00:00 UTC. Диапазон 64-битного знакового — примерно 292 миллиарда лет до и после epoch.
Unix-время не учитывает leap seconds: Unix-время предполагает ровно 86 400 секунд в день (24 × 60 × 60). На самом деле leap seconds иногда добавляются IERS, чтобы синхронизировать UTC с вращением Земли. Это значит, что Unix-время не идеально линейно относительно TAI (Международное атомное время), и разница растёт со временем. Для большинства приложений это нерелевантно, но точные timekeeping-системы должны учитывать.

Лучшие практики работы с timestamp

Всегда храните timestamp в UTC: Храните timestamp в UTC (или как Unix timestamp) и конвертируйте в локальное время только на слое отображения. Смешение часовых поясов в БД — частый источник трудно воспроизводимых багов, особенно при переходах DST.
Миллисекундная точность для современных API: Большинство современных API, JavaScript-окружений и БД используют миллисекунды (13 цифр), а не секунды (10). При интеграции с внешними системами подтверждайте ожидаемую точность — передача миллисекундного timestamp вместо секундного даст дату примерно на 11 000 лет вперёд.
Опасайтесь проблемы 2038 года: Системы, хранящие Unix timestamp в 32-битных знаковых, переполнятся 19 января 2038 в 03:14:07 UTC. Аудитируйте legacy-системы на 32-битные timestamp-поля и мигрируйте на 64-битные или ISO 8601 строки. Большинство современных языков и БД по умолчанию используют 64-битные, но embedded-системы, старые БД и файловые системы могут быть в зоне риска.
Никогда не доверяйте клиентским часам для безопасности: Часы клиентских устройств можно установить в любое значение случайно или злонамеренно. Никогда не используйте клиентский timestamp для security-логики (проверка истечения JWT, тайм-ауты сессий, rate limiting). Всегда валидируйте timestamp на сервере с доверенного источника времени.
ISO 8601 для человекочитаемого обмена: Когда нужен формат timestamp одновременно машинно-разбираемый и человекочитаемый — например, в логах, файлах конфигурации или ответах API, которые читает разработчик — ISO 8601 (например, 2025-03-14T15:37:12Z) — лучший выбор. Лексикографически сортируем, однозначен и поддерживается практически всеми современными парсерами.

Часто задаваемые вопросы

Почему Unix-время начинается с 1 января 1970?

Дата Unix epoch 1 января 1970 выбрана разработчиками Unix в Bell Labs в конце 1960-х как удобная круглая стартовая точка — недавняя и вычислительно практичная. Тогда timestamp хранились в 32-битных целых, поэтому epoch должен был быть достаточно близок к настоящему, чтобы типичные даты помещались в число разумного размера. 1970 был просто чистым круглым годом после начала разработки системы. Глубокого технического значения именно у 1 января 1970 нет — это инженерный прагматизм. Другие системы выбрали другие epoch: классический Macintosh toolbox — 1 января 1904; Windows NT — 1 января 1601; GPS-время — с 6 января 1980. Каждый отражает эпоху и ограничения дизайна выбравшей его системы. Unix epoch закрепился, потому что Unix стал доминирующей ОС в вычислениях, и каждый крупный язык программирования, БД и ОС в итоге приняли Unix-время как универсальный стандарт. Сегодня Unix epoch — фактически универсальная константа в вычислениях. Известное последствие выбора: даты до 1 января 1970 представлены отрицательными числами, что некоторые старые системы не обрабатывают. Для исторических дат и астрономических расчётов иногда предпочтительнее альтернативные форматы. Для подавляющего большинства разработки ПО Unix epoch покрывает все релевантные даты с запасом.

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

Проблема 2038 года (Y2K38 или Epochalypse) — вычислительная проблема, которая затронет системы, хранящие Unix timestamp как 32-битные знаковые целые. 32-битное знаковое может содержать значения от -2 147 483 648 до 2 147 483 647. Как Unix timestamp максимум 2 147 483 647 соответствует 19 января 2038 в 03:14:07 UTC. Через секунду счётчик переполнится и завернётся в самое отрицательное представимое значение, что соответствует 13 декабря 1901 — заставляя системы интерпретировать будущие даты как далёкое прошлое. Последствия — от тривиальных до катастрофических в зависимости от использования timestamp. Системы могут отвергать валидные будущие даты при валидации, неверно сортировать time-sensitive записи, неправильно вычислять истечение сертификатов и токенов или падать при встрече с переполнением. Исправление прямолинейно: миграция на 64-битные знаковые целые для хранения timestamp. 64-битный timestamp представляет даты ~292 миллиарда лет до и после epoch — далеко за пределами любых практических задач. Большинство современных ОС, языков и БД уже используют 64-битные внутри. Риск — в legacy-коде, embedded-системах, 32-битных ОС в production, метаданных файловых систем (FAT32 timestamp-поля) и колонках БД, определённых как INT, а не BIGINT. Разработчикам стоит аудитировать системы сейчас. Миграция с 32 на 64 бит должна произойти до 2038, и на практике любые системы с долгоживущими записями (ипотеки, инфраструктурные активы, юридические документы) могут столкнуться с проблемой раньше — при вводе будущих дат в затронутые поля.

В чём разница между секундами, миллисекундами и микросекундами в timestamp?

Unix timestamp бывают трёх частых точностей, отличаемых по числу цифр: **Секунды (10 цифр)**: Оригинальный и самый частый формат. 1741965432 представляет конкретную секунду. Используют: системные вызовы Unix/Linux (time()), большинство утилит Unix, JWT-токены (claims iat, exp), HTTP-заголовки (Last-Modified) и многие REST API. **Миллисекунды (13 цифр)**: Тысячная секунды. 1741965432000 — тот же момент, умноженный на 1000. Используют: JavaScript Date.now(), Java System.currentTimeMillis(), Node.js, большинство современных JS/TS API, Redis и многие клиенты БД. 13-значный timestamp в JSON-ответе — почти наверняка миллисекунды. **Микросекунды (16 цифр)**: Миллионная секунды. 1741965432000000 — тот же момент, умноженный на 1 000 000. Используют: типы TIMESTAMP/TIMESTAMPTZ PostgreSQL, Python time.time_ns() (хотя возвращает наносекунды), high-frequency trading, анализ сетевых пакетов. Самая частая ошибка — смешение точностей: передача миллисекундного timestamp в функцию, ожидающую секунды. Это даёт даты ~11 574 лет в будущем. Всегда проверяйте документацию API.

Учитывает ли Unix-время leap seconds?

Нет — Unix-время не учитывает leap seconds, и это одно из его известных ограничений для precision timekeeping. Leap seconds иногда вставляются (или теоретически удаляются, хотя удалений не было) IERS, чтобы синхронизировать UTC с слегка нерегулярным вращением Земли. На 2026 год вставлено 27 leap seconds с 1972 года. Unix-время предполагает идеально регулярный календарь с ровно 86 400 секунд в день. При вставке leap second в реальном мире есть секунда, которую Unix-время игнорирует. Разные ОС обрабатывают это по-разному: Linux традиционно «размазывает» leap second, замедляя часы вокруг точки вставки (подход Google, «leap smearing»); некоторые системы дублируют секунду 23:59:60 UTC; другие просто пропускают коррекцию. Для подавляющего большинства приложений ~27 секунд накопленного расхождения за 50+ лет совершенно нерелевантны. Где leap seconds важны: GPS-синхронизация, астрономические наблюдения, сетевые протоколы синхронизации (PTP/IEEE 1588) и любая система, точно коррелирующая Unix timestamp с TAI.

Могут ли Unix timestamp быть отрицательными?

Да, Unix timestamp могут быть отрицательными — это легитимный и хорошо определённый способ представить даты до Unix epoch (1 января 1970, 00:00:00 UTC). Каждая секунда до epoch — декремент на 1 от нуля. Например, -1 = 31 декабря 1969 в 23:59:59 UTC; -86400 = 31 декабря 1969 в 00:00:00 UTC (ровно за день до epoch); -2208988800 = 1 января 1900 в 00:00:00 UTC. Большинство современных языков и ОС поддерживают отрицательные timestamp. Python datetime.fromtimestamp(-86400) корректно возвращает 31 декабря 1969. JavaScript new Date(-86400 * 1000) корректно отображает ту же дату. PostgreSQL хранит timestamp как 8-байтовые целые и корректно обрабатывает даты тысячи лет до epoch. Однако есть оговорки. Некоторые старые системы, библиотеки или драйверы БД могут не поддерживать отрицательные timestamp корректно. 32-битные системы с беззнаковыми целыми не могут представить отрицательные значения вовсе. БД с типами UNSIGNED BIGINT или DATETIME могут отвергать отрицательные значения или интерпретировать их как далёкие будущие даты. Для исторических дат (до 1970) часто безопаснее хранить дату как ISO 8601 строку или использовать нативный тип даты БД, чем полагаться на отрицательные Unix timestamp ради переносимости.

Как получить текущий Unix timestamp в JavaScript, Python и других языках?

Получение текущего Unix timestamp прямолинейно во всех основных языках: **JavaScript / TypeScript:** ```javascript // Секунды (большинство API ожидают это) const seconds = Math.floor(Date.now() / 1000); // Миллисекунды (нативно в JavaScript) const milliseconds = Date.now(); ``` **Python:** ```python import time seconds = int(time.time()) # 1741965432 import datetime milliseconds = int(datetime.datetime.now(datetime.UTC).timestamp() * 1000) ``` **Go:** ```go import "time" seconds := time.Now().Unix() milliseconds := time.Now().UnixMilli() microseconds := time.Now().UnixMicro() ``` **Java:** ```java long seconds = System.currentTimeMillis() / 1000L; long milliseconds = System.currentTimeMillis(); long seconds2 = Instant.now().getEpochSecond(); ``` **PHP:** $seconds = time(); $milliseconds = round(microtime(true) * 1000); **Ruby:** seconds = Time.now.to_i; milliseconds = (Time.now.to_f * 1000).to_i **Bash:** date +%s # секунды; date +%s%3N # миллисекунды (GNU date) Главное помнить: JavaScript нативно работает в миллисекундах, а почти все остальные языки по умолчанию — в секундах. Всегда явно документируйте используемую точность.

Как конвертировать epoch-время в человекочитаемую дату?

Три быстрых способа конвертировать epoch-время в человекочитаемую дату: **1. Используйте этот онлайн-конвертер (быстрее всего)** Вставьте epoch-timestamp в поле ввода. Инструмент автоопределит секунды, миллисекунды или микросекунды и мгновенно покажет результат в UTC, локальном поясе, ISO 8601 и относительном времени. **2. Используйте код** JavaScript: new Date(1741965432 * 1000).toISOString() возвращает '2025-03-14T15:37:12.000Z'. Python: from datetime import datetime, UTC; datetime.fromtimestamp(1741965432, UTC) — тот же результат. JavaScript ожидает миллисекунды, Python — секунды — это самый частый источник багов. **3. Используйте командную строку** Linux/macOS с GNU date: date -d @1741965432 (Linux) или date -r 1741965432 (macOS). Windows PowerShell: [DateTimeOffset]::FromUnixTimeSeconds(1741965432).DateTime. Все три способа дают одинаковый результат.

Какой текущий Unix timestamp прямо сейчас?

Текущий Unix timestamp показан в живых часах вверху страницы и обновляется каждую секунду. Unix timestamp — это просто число секунд с 1 января 1970 00:00:00 UTC, увеличивающееся ровно на 1 в секунду. Программно: - **JavaScript**: Math.floor(Date.now() / 1000) (секунды) или Date.now() (миллисекунды) - **Python**: import time; int(time.time()) - **Bash**: date +%s На 2026 год текущий Unix timestamp — в диапазоне 1.77 миллиарда (10 цифр). 2 миллиарда будет около мая 2033, а максимум 32-битных систем (2 147 483 647) — 19 января 2038 в 03:14:07 UTC — проблема 2038 года. Сохраните страницу в закладки, чтобы текущий epoch был всегда в одном клике.

Нужно отладить timestamp в ответе API — как конвертировать?

Скопируйте значение timestamp из ответа API (обычно 10 или 13 цифр в JSON-поле «created_at» или «timestamp»). Вставьте напрямую в поле ввода — инструмент автоопределит секунды или миллисекунды и мгновенно покажет UTC, локальное время и ISO 8601. Если timestamp вложен в JWT, сначала декодируйте payload JWT (Base64URL-кодирован) для извлечения iat, exp, nbf, затем вставьте сюда. Для batch-отладки используйте: new Date(timestamp * 1000).toISOString() в консоли браузера для быстрой проверки нескольких timestamp.

Как получить текущий Unix timestamp в Python, JavaScript или Go?

JavaScript: Math.floor(Date.now() / 1000) для секунд или Date.now() для миллисекунд. Python: import time; int(time.time()) для секунд или int(time.time() * 1000) для миллисекунд. Go: time.Now().Unix() для секунд, time.Now().UnixMilli() для миллисекунд, time.Now().UnixMicro() для микросекунд. JavaScript нативно в миллисекундах, Python и Go по умолчанию в секундах — самый частый источник timestamp-багов при интеграции систем на разных языках. Всегда документируйте ожидаемую точность в OpenAPI/Swagger.

Что происходит с Unix timestamp при переходах DST?

Unix timestamp полностью не подвержены изменениям летнего времени, потому что основаны на UTC, не соблюдающем DST. Когда часы «переводятся вперёд» или «назад» в локальном поясе, Unix timestamp продолжает увеличиваться ровно на 1 в секунду без разрывов и повторов. Это одно из ключевых преимуществ хранения времени как Unix timestamp вместо локальных datetime-строк. Однако если конвертировать timestamp в локальное время во время перехода DST, одно и то же локальное время может соответствовать двум разным Unix timestamp (во время «возврата назад», когда час повторяется). Всегда храните и сравнивайте timestamp в UTC, конвертируйте в локальное только для отображения.

У меня timestamp в миллисекундах — как конвертировать в секунды?

Разделите миллисекундный timestamp на 1000 и отбросьте дробную часть. JavaScript: Math.floor(ms / 1000). Python: ms // 1000 (целочисленное деление). Например, 1741965432000 (миллисекунды) становится 1741965432 (секунды). Миллисекундные timestamp узнаются по 13-значной длине против 10-значной у секундных. Этот инструмент автоопределяет точность. Обратная конвертация (секунды → миллисекунды) — умножение на 1000: 1741965432 * 1000 = 1741965432000. Не передавайте миллисекундное значение в функцию, ожидающую секунды — результат будет ~11 574 лет в будущем.