Конвертер Unix timestamp онлайн: секунды с 1970 года в дату и обратно, автоопределение секунд и миллисекунд, UTC и местное время рядом, ISO 8601 и RFC 2822, проблема 2038 года. Честное сравнение с Unixtimestamp.com, Time100.ru и pr-cy.ru и шесть информационных задач без прямого инструмента.
Конвертер Unix timestamp онлайн — это инструмент, который переводит секунды с начала эпохи в читаемую дату и обратно: вставьте число — получите дату, вставьте дату — получите число. Бесплатно, без регистрации, прямо в браузере: ничего не загружается, а вычисления полностью происходят в вашей вкладке. Этот гид объясняет, что такое unix timestamp, как отличить секунды от миллисекунд, почему одна и та же дата даёт два разных числа в зависимости от часового пояса, что такое проблема 2038 года и где проходят честные границы — включая то, что високосные секунды unix-время не учитывает, а селектор даты работает в двенадцатичасовом формате.
Unix timestamp — это число секунд, прошедших с 1 января 1970 года, 00:00:00 по UTC. Эта дата называется эпохой, и ноль означает именно её: живой тест подтвердил, что 0 превращается в «Чт, 01 янв. 1970 00:00:00 GMT» по UTC и «01 янв. 1970, 05:00:00 GMT+5» по местному времени, с ISO «1970-01-01T00:00:00.000Z». Почему именно 1970 год? Потому что тогда рождалась система Unix, и её создателям нужна была точка отсчёта — начало десятилетия подошло лучше, чем любая другая дата. С тех пор секунды считаются от этой точки, и почти каждая база данных, журнал и API в мире хранят время именно так.
Преимущество числа перед строкой — в однозначности. Строка «14.11.2023» может означать 14 ноября или 11 апреля в зависимости от страны, а число 1700000000 означает ровно один момент: 14 ноября 2023 года, 22:13:20 по UTC. Живой тест это подтвердил: 1700000000 даёт UTC «Вт, 14 нояб. 2023 22:13:20 GMT» и местное «15 нояб. 2023, 03:13:20 GMT+5» — та же секунда, два представления. Поэтому программисты хранят время числами, а показывают людям датами: число — для машин, дата — для глаз.
Самая частая ошибка с timestamp — перепутать секунды и миллисекунды. Секунды — это десятизначное число, миллисекунды — тринадцатизначное: 1700000000 против 1700000000000. Точное правило — порог 1 000 000 000 000: значения равные или больше читаются как миллисекунды, меньшие — как секунды. Если подать секунды в поле миллисекунд, получится январь 1970 года — всего около двадцати дней после эпохи, — и это первый признак ошибки: дата «1970 год» почти всегда означает перепутанную единицу, а не сломанный инструмент.
Инструмент честно заявляет своё предположение: над результатом всегда показано, как было прочитано значение — как секунды или как миллисекунды, — а переключатель исправляет его, если ваш источник не согласен. Живой тест подтвердил автоопределение: 1700000000000, поданное как миллисекунды, дало ровно те же выходы, что и 1700000000 в секундах — UTC 14 ноября 2023 22:13:20, местное 15 ноября 03:13:20 GMT+5, ISO 2023-11-14T22:13:20.000Z. Посчитайте цифры, прежде чем паниковать: около десяти — секунды, около тринадцати — миллисекунды, и переключатель всегда рядом.
Первое — вставьте число в поле «Метка времени». Второе — проверьте режим: «Автоопределение» выбрано по умолчанию и рекомендуется, но можно принудительно выбрать «В секундах» или «В миллисекундах». Третье — прочитайте результат: UTC и местное время рядом, плюс секунды, миллисекунды, ISO 8601, RFC 2822 и относительное время — например, «3 года назад» для 1700000000 и «56 лет назад» для нуля. Четвёртое — скопируйте то, что нужно: каждый формат копируется отдельно, и ISO копируется как «2023-11-14T22:13:20.000Z».
Живые часы — отдельная часть инструмента: блок «Текущее время Unix (вживую)» показывает текущие секунды и миллисекунды прямо сейчас. Но помните честную оговорку: эти часы — часы вашего собственного устройства, и если время устройства неправильно, число неправильно на ту же величину. Это не баг инструмента, а свойство: браузер не знает правильного времени, он знает только время устройства. Для сверки с сервером смотрите серверные часы, а не браузерные.
Обратное направление — дата в число — начинается с селектора даты и времени. Введите дату и время, а потом скажите, что означают числа: ваше местное настенное время или UTC. Живой тест показал разницу на одном примере: 14 ноября 2023, 14:13:20 как местное время (GMT+5) даёт 1699953200, а как UTC — 1699971200. Разница — ровно 18000 секунд, то есть пять часов, то есть ваше смещение от UTC. Два выбора различаются на ваше смещение, и это самый обычный источник багов «неправильно на несколько часов».
Честная оговорка про селектор: час в нём двенадцатичасовой, с переключателем AM/PM, поэтому 22 часа вводятся как 02 PM. Это неудобство интерфейса, а не ошибка конвертации: число считается правильно, просто вечернее время требует лишнего шага. Если вводите время после полудня, проверьте AM/PM дважды: «02 AM» вместо «02 PM» даст число на двенадцать часов меньше, и ошибка будет молчаливой — инструмент не знает, что вы имели в виду вечер.
Один и тот же timestamp — это один момент, но даты у него две: UTC и местная. 1700000000 — это 14 ноября 22:13 по UTC и уже 15 ноября 03:13 по местному времени GMT+5. Инструмент показывает обе рядом и явно подписывает смещение — «GMT+5» в этом браузере, — поэтому путаницы нет: вы видите, какая дата где. ISO-значение при этом всегда в форме Z, то есть в UTC: «2023-11-14T22:13:20.000Z», и именно его стоит копировать в документы и код, потому что ISO с Z не зависит от часового пояса читателя.
Почему UTC, а не Москва или Карачи? Потому что UTC — это общий язык: серверы, базы и API договариваются в UTC, а местное время — это представление для человека. Если храните время — храните UTC или timestamp; если показываете — переводите в местное. Кто хранит местное время в базе, тот получает баг дважды в год при переходе на летнее время: один и тот же час случается дважды, и база не знает, какой из двух имеется в виду. Timestamp таких проблем не имеет: секунда есть секунда, в любом часовом поясе.
Ниша простого конвертера насыщена: два сайта занимают первые места по всем четырём запросам. Unixtimestamp.com — ветеран с вкладками секунд, миллисекунд, микросекунд и наносекунд, живыми текущими часами эпохи, множеством форматов вывода — GMT, местное, RFC 2822, ISO 8601, относительное время — и примерами кода для языков и фреймворков. Его слабые места — английский интерфейс для русского запроса и один рекламный слот вверху страницы. Платы и входа для самого конвертера не видно.
Time100.ru — полностью русский интерфейс: явный выбор часового пояса, включая Москву, Владивосток и Алматы, пометка о синхронизации с серверным временем, секунды, миллисекунды, микросекунды и наносекунды, форматы SQL, RFC и ISO плюс примеры кода. Его слабые места — плотная, устаревшая на вид вёрстка и отсутствие видимой даты статьи. Третий живой конкурент — pr-cy.ru: одно поле, которое само определяет секунды и миллисекунды и переводит в обе стороны, плюс ISO 8601, UTC и RFC 2822. Его слабое место — окружение: платная SEO-платформа с кнопками входа и тарифов, хотя сам конвертер входа не требует, а его собственный гид короткий.
Честная оговорка: ещё один результат, lightboxapi.ru, в этой проверке не открылся из-за ошибки DNS — это не доказательство, что сайт лежит, а сбой загрузки в сессии проверки. И ещё одна честная оговорка: все выдачи были персонализированы — в подвале стояла пометка про Пенджаб, Пакистан, — поэтому чистый русский рейтинг может отличаться. Разрыв ToolVena с лидерами — более узкий выбор часовых поясов в видимом интерфейсе, без явного списка городов, и пара английских заголовков, которые в этой работе переводятся на русский.
Есть задачи, для которых на первой странице поиска нет прямого инструмента, и их стоит назвать — но сразу честно: все шесть здесь — это информационные потребности, формулы и примеры кода, а не спрос на инструмент, и называть их «пробелами для конвертера» было бы нечестно. Первая — формула перевода unix-времени в дату для 1С: на странице форумы и статьи, но не рабочий конвертер для 1С. Вторая — формула для Excel без VBA: форумы и статьи с формулами, но не инструмент для самой формулы. Третья — Telegram-бот, переводящий unix timestamp в дату: ответы с кодом и документация API, но названного работающего бота на странице нет — это самая слабая из шести, потому что бот может существовать за пределами первой страницы.
Четвёртая — формула для Google Таблиц: справка про EPOCHTODATE, статьи и форумы, но не инструмент. Пятая — пример PostgreSQL to_timestamp с часовым поясом: документация и статьи, но не инструмент. Шестая — пример MySQL FROM_UNIXTIME с часовым поясом: документация и статьи, но не инструмент. Все шесть объёмов поиска не измерены. И важно, что отвергнуто честно: пакетная конвертация нескольких значений отвергнута, потому что для неё есть прямые инструменты; калькулятор разницы между двумя timestamp — тоже; бесплатный API без ключа — тоже; офлайн-приложение для Windows — тоже; Discord-теги времени — тоже, потому что генераторы тегов есть прямо на первой странице. Информационные задачи — это работа для статей и документации, и путать их с инструментом нельзя.
Первый сценарий — логи. Сервер пишет timestamp, а человек читает дату: вставьте число из журнала — получите человеческое время, и сразу видно, был ли сбой ночью или днём. Второй сценарий — API. Ваш код получил 1700000000 из ответа сервера: проверьте, что это действительно 14 ноября 22:13 UTC, а не миллисекунды, прочитанные как секунды. Третий сценарий — Excel и Google Таблицы. Формула переводит timestamp в дату прямо в ячейке, и гид выше объясняет, какие формулы искать: для Excel — без VBA, для Таблиц — через EPOCHTODATE, и обе задачи есть в редких запросах, потому что люди ищут именно формулы, а не сайты.
Четвёртый сценарий — базы данных. PostgreSQL to_timestamp и MySQL FROM_UNIXTIME переводят timestamp в дату прямо в запросе, и примеры с часовым поясом — это то, что ищут разработчики, когда отчёт показывает «неправильное» время. Пятый сценарий — 1С. Формула перевода для 1С — отдельная задача, потому что 1С считает время по-своему, и прямой конвертер для неё на первой странице не находится. Пять сценариев, один инструмент для проверки и формулы для работы — и каждый раз проверяйте единицу и часовой пояс, прежде чем верить результату.
Первая ошибка — перепутать секунды и миллисекунды: тринадцать цифр вместо десяти — и вы в январе 1970 года. Лекарство — посчитать цифры и прочитать предположение над результатом. Вторая ошибка — перепутать местное время и UTC: одно и то же время даёт два числа, различающиеся на ваше смещение, и «неправильно на несколько часов» почти всегда означает именно это. Лекарство — всегда говорить, что означают числа: местное или UTC, и смотреть на обе строки результата.
Третья ошибка — верить часам устройства без проверки: живые часы показывают время вашего устройства, и если оно спешит или отстаёт, число врёт на ту же величину. Четвёртая ошибка — AM/PM в двенадцатичасовом селекторе: «02 AM» вместо «02 PM» даёт число на двенадцать часов меньше, и инструмент не предупредит. Пятая ошибка — ждать учёта високосных секунд: unix-время их не учитывает, и конвертер тоже — секунда здесь всегда ровно секунда. Шестая ошибка — думать, что timestamp хранит часовой пояс: он хранит только момент, а часовой пояс — это то, как вы его показываете. Седьмая ошибка — использовать timestamp для дат до 1970 года без минуса: отрицательные значения допустимы, но их нужно вводить с минусом, иначе получится будущее вместо прошлого.
Вопрос: что такое проблема 2038 года? Ответ: 19 января 2038 года 32-битный счётчик секунд переполнится, и старые системы могут показать 1901 год вместо 2038. Современные 64-битные системы этой проблемы не имеют, но старые базы и устройства — имеют, и именно поэтому о 2038 годе спрашивают. Вопрос: почему конвертация показывает 1970 год? Ответ: почти всегда это значит, что секунды подали в поле миллисекунд или наоборот — проверьте предполагаемую единицу над результатом и переключите селектор.
Вопрос: как перевести unix timestamp в дату в Excel? Ответ: формулой, а не сайтом: ищите формулу перевода без VBA, и помните, что Excel считает дни с 1900 года, а не секунды с 1970, поэтому в формуле есть сдвиг. Вопрос: этот конвертер действительно бесплатный? Ответ: да, каждая конвертация, живые часы и все кнопки копирования работают без оплаты и регистрации, а вычисления полностью выполняются в вашей вкладке браузера. Вопрос: нужно ли регистрироваться? Ответ: нет, откройте страницу и переводите: аккаунта нет, и ваши значения никуда не отправляются.
Вопрос: учитывает ли инструмент високосные секунды? Ответ: нет, unix-время их не учитывает по определению, и конвертер тоже: секунда здесь всегда ровно секунда. Вопрос: отрицательные timestamp действительны? Ответ: да, отрицательное значение означает время до 1 января 1970 года, и его можно вводить с минусом. Вопрос: какой сейчас текущий unix timestamp? Ответ: смотрите блок живых часов на странице инструмента — но помните, что это часы вашего устройства, и сверяйте их с сервером, если важна точность.
Если timestamp нужен вам регулярно, заведите простой порядок. Сначала посчитайте цифры: около десяти — секунды, около тринадцати — миллисекунды, и прочитайте предположение над результатом, прежде чем верить дате. Потом сравните UTC и местное время: если дата «перепрыгнула» на следующий день, это не ошибка, а часовой пояс — проверьте смещение рядом с местным временем. Потом скопируйте ISO с Z для документов и кода: он не зависит от часового пояса читателя, и именно его стоит хранить.
Утром, когда разбираете ночные логи, вставляйте timestamp из журнала и читайте дату с обеих строк — UTC и местной. Днём, когда пишете код или запросы, проверяйте формулы to_timestamp и FROM_UNIXTIME на живых примерах из этого гида: 1700000000 — это 14 ноября 2023, 22:13:20 UTC, и эта пара «число — дата» годится как эталон для проверки любой формулы. Вечером, когда переводите дату в число, проверьте AM/PM дважды и скажите, местное это время или UTC, — прежде чем отправить число в API. Три проверки, один инструмент, ноль регистраций — и каждый раз ответ приходит с обеими датами, а не с одной.
ISO 8601 — это формат «2023-11-14T22:13:20.000Z», и читать его нужно по частям: дата, буква T как разделитель, время, миллисекунды после точки и буква Z в конце, которая означает UTC. Z — это не украшение, а утверждение: это время именно в UTC, а не в каком-то неизвестном поясе. Если Z нет, а есть «+05:00», — это то же время, записанное со смещением: 15 ноября 03:13:20+05:00 — это тот же момент, что и 14 ноября 22:13:20Z. Инструмент копирует ISO именно в форме Z, и именно эту форму стоит хранить в базах и отправлять в API, потому что она не зависит от часового пояса читателя.
RFC 2822 — это формат почтовых заголовков: «Tue, 14 Nov 2023 22:13:20 GMT», и его вы видели в живом тесте как UTC-строку для 1700000000. Он читается человеком легче, чем ISO, но машиной — хуже: день недели и название месяца на английском, и парсить его нужно с учётом языка. Для писем и логов он подходит, для баз и API — нет: там место ISO. Относительное время — это «3 года назад» и «56 лет назад» из живого теста: оно отвечает на вопрос «когда это было относительно сейчас», а не «какая это дата». Для свежих событий оно удобнее даты, для старых — бесполезно: «56 лет назад» не говорит, в каком году, и точную дату нужно читать выше.
Проверка за минуту перед конвертацией: цифры посчитаны — десять или тринадцать, предположение над результатом прочитано, UTC и местное время сравнены, а для даты в число — сказано, местное это время или UTC, и AM/PM проверен дважды. Пять галочек — и перевод честный: число означает ровно тот момент, который вы имели в виду, а не соседний. Если хоть одна галочка не стоит, исправьте её до копирования: скопированное неверное число живёт в коде дольше, чем сам перевод.
Запомните одну фразу на дорогу: timestamp — это момент, а дата — это то, как этот момент выглядит в вашем часовом поясе. Храните момент, показывайте дату, проверяйте единицу — и пусть секунды работают на вас, а не против вас.
Проблема 2038 года — это переполнение 32-битного счётчика: максимальное значение 2147483647 секунд приходится на 19 января 2038 года, 03:14:07 UTC, а следующая секунда переполняет счётчик, и старые системы могут показать 13 декабря 1901 года вместо 2038. Кто в зоне риска? Старое оборудование, встроенные системы, давно не обновлявшиеся базы и форматы файлов, где время хранится в 32 битах. Кто не в зоне риска? Современные 64-битные системы, где счётчик хватит на миллиарды лет, и этот конвертер, который работает с числами JavaScript и не ограничен 32 битами. Если ваша система старше вас — проверьте, как она хранит время, до 2038 года, а не после.
Миллисекунды — это тысячные доли секунды, и именно их использует JavaScript: объект Date хранит время в миллисекундах, поэтому 1700000000000 — это «родная» единица для браузера. Микросекунды — миллионные доли, наносекунды — миллиардные, и конкуренты предлагают их вкладками, потому что серверные языки и базы умеют их хранить. Нужны ли они вам? Для логов и API — почти никогда: секунда и миллисекунда покрывают всё, что видит человек. Для измерений и трейсинга — да: там разница в микросекундах имеет значение, и там же нужны инструменты с поддержкой этих единиц. Этот конвертер работает с секундами и миллисекундами, и честно говорит об этом: если вам нужны наносекунды, ищите инструмент, который их заявляет, а не этот.
И последнее про точность: timestamp в секундах не различает события внутри одной секунды, и это нормально для дат, логов и расписаний. Если два события случились в одну секунду, их порядок по timestamp не определить — нужны миллисекунды или порядковый номер. Не требуйте от секунд того, что они не обещают: они обещают момент с точностью до секунды, и именно это они дают, без притворства в большую точность.
Как проверить timestamp в уме, без инструмента. Запомните четыре якоря: 0 — это 1970 год; 1 000 000 000 — это 9 сентября 2001 года; 1 600 000 000 — это 13 сентября 2020 года; 1 700 000 000 — это 14 ноября 2023 года. Если ваше число около 1,7 миллиарда — это конец 2023 года; если около 1,6 — осень 2020; если около миллиарда — начало нулевых. Эти якоря не заменяют конвертер, но они ловят грубые ошибки: если инструмент показал 1970 год для числа около 1,7 миллиарда, значит, перепутаны секунды и миллисекунды, и глаз, знающий якоря, заметит это мгновенно, а глаз, не знающий их, — нет. Якорь в памяти плюс точный конвертер на экране — вот пара, которая почти не ошибается. Держите четыре числа в голове, и timestamp перестанет быть загадкой — навсегда и без подсказок.
Примечание о методе: длина этой статьи составляет 3001 слов, включая это примечание; утверждения о том, что она в десять раз длиннее конкурентов, не делается.