Конвертер временных меток
Преобразуйте Unix-метку времени в читаемую дату — и обратно. Вы получите секунды, миллисекунды, ISO 8601, UTC, местное время, день недели, строку RFC 2822 и
Преобразуйте временные метки Unix в читаемые даты и обратно — в обе стороны и как в секундах, так и в миллисекундах. Вставьте 1735689600 или 2026-01-01T00:00:00Z и посмотрите эквивалент в UTC, в вашем местном часовом поясе и в распространённых форматах, таких как ISO 8601 и RFC 2822.
Это нужно постоянно: при чтении логов, отладке API, который возвращает секунды эпохи, или проверке того, что срок действия токена действительно такой, как вы думаете. Преобразование точное и выполняется локально, а если значение похоже на миллисекунды, а не на секунды, инструмент об этом предупредит.
Как преобразовать временную метку Unix
Вставьте метку времени или дату
Посмотрите преобразованные значения в UTC и местном времени
Скопируйте нужный формат
Частые вопросы
Секунды или миллисекунды?
Десять цифр — это обычно секунды, тринадцать — обычно миллисекунды. Инструмент определяет вероятную единицу измерения и позволяет переключить её, если результат выглядит неправильно.
Что такое эпоха Unix?
Это количество секунд с 1 января 1970 года, 00:00:00 UTC, без учёта високосных секунд. Это стандартный способ хранить момент времени.
Какой часовой пояс используется?
Показываются оба: UTC и местный часовой пояс вашего браузера, чтобы можно было сравнить то, что сервер пишет в логах, с тем, что вы видите на часах.
Поддерживаются ли даты до 1970 года?
Да, отрицательные значения обозначают даты до начала эпохи, а далёкое будущее работает в пределах диапазона дат JavaScript.
Можно ли получить метку времени для даты?
Да, преобразование работает в обе стороны: введите дату и получите значение эпохи.
Что-нибудь загружается на сервер?
Нет, это локальные вычисления.
Кратко
| Ввод | текст |
|---|---|
| Несколько файлов | Нет |
| Где работает | В вашем браузере — файлы никуда не загружаются |
| Работает офлайн | Да — после загрузки страницы |
| Цена | Бесплатно, без регистрации, без водяных знаков |
Где конвертации незаметно ломаются
Большинство ошибок конвертации — не про синтаксис, а про смысл. Столбец CSV с почтовыми индексами теряет ведущие нули в тот момент, когда таблица решает, что это число; длинный идентификатор выходит за пределы точности чисел с плавающей запятой; даты меняют смысл в зависимости от того, что идёт первым — день или месяц. Ключи JSON не упорядочены, а массивы упорядочены, и инструмент, сортирующий ключи, ничего не меняет, тогда как сортирующий массивы меняет данные. Unicode — ещё одна ловушка: текст может прийти в UTF-8, в UTF-16 или с BOM, и декодер, который угадает неверно, превращает буквы с диакритикой в «кракозябры». Прежде чем доверять любой конвертации, выборочно проверьте первую и последнюю строку, любое поле с ведущими нулями и любое поле, содержащее кавычки, запятые или переводы строк.
Как выбрать формат данных
JSON — выбор по умолчанию для всего, что возвращает API или читает программа: он естественно работает с вложенными структурами, числами, логическими значениями и null, и его разбирает любой язык. CSV компактнее и открывается прямо в таблице, но в нём нельзя выразить вложенность и нет общего стандарта для разделителя, кавычек и кодировки — именно здесь конвертации и ломаются. XML многословен, но несёт атрибуты, смешанное содержимое и схемы, поэтому до сих пор доминирует в форматах документов и устаревших интеграциях. YAML самый читаемый для конфигурации, но чувствителен к пробелам и удивляет приведением типов («no» превращается в false, версия вроде 1.10 — в 1.1). Выбирайте формат, который предпочитает потребляющий инструмент, а не тот, что выглядит красивее.