Если ты когда-либо смотрел на число вроде 1717200000 и задавался вопросом, какую дату оно представляет, ты не одинок. Умение конвертировать unix timestamp в дату — это базовый навык для разработчиков, работающих с API, базами данных и серверными системами. Unix timestamp — это просто количество секунд (или миллисекунд), прошедших с 1 января 1970 года в 00:00:00 UTC, точки отсчета, известной как эпоха Unix. Это руководство покажет тебе механизмы преобразования времени, работу с часовыми поясами и практические примеры кода на JavaScript, Python и SQL, чтобы ты мог перестать гадать и начать конвертировать с уверенностью.
Ключевые выводы:
- Unix timestamp считает секунды с 1 января 1970 года UTC (эпоха 0), что делает его нейтральным к часовым поясам по дизайну.
- Всегда проверяй, указан ли timestamp в секундах или миллисекундах перед конвертацией — их путаница является самой частой причиной багов.
- Смещения часовых поясов нужно применять явно после конвертации в UTC, а не до.
- JavaScript, Python и SQL имеют встроенные функции для преобразования unix в дату, но у каждого есть свои особенности, на которые стоит обратить внимание.
Содержание
Что такое Unix Timestamp?
Unix timestamp представляет единственный, однозначный момент времени в виде целого числа. Отсчет начался 1 января 1970 года в 00:00:00 UTC — момент, называемый "эпохой 0". Каждая секунда, прошедшая с тех пор, добавляет единицу к счетчику. Именно эта простота сделала его универсальным форматом времени для вычислительных систем.
В самом числе нет месяцев, високосных лет, перехода на летнее время. Timestamp всегда основан на UTC, что означает, что одно и то же число ссылается на точно тот же момент времени независимо от того, где расположен сервер или пользователь. Это одновременно его главная сила и источник большинства путаницы разработчиков при работе с форматами времени.
Для более глубокого понимания того, как эпоха времени стала основой современных вычислений, смотри нашу статью Эпоха времени: основа Unix Timestamps.
Важное различие: не все Unix timestamps считают в секундах. Некоторые системы, особенно JavaScript-среды и многие REST API, используют миллисекунды. Timestamp 1717200000 указан в секундах; 1717200000000 — тот же момент в миллисекундах. Их путаница — самая частая ошибка при преобразовании времени. Прежде чем написать хотя бы строчку кода, убедись в единице измерения, которую использует твой источник.
Не уверен, какую единицу должна использовать твоя система? Ознакомься с Секунды vs Миллисекунды vs Микросекунды: какой Unix Timestamp выбрать? для практического разбора.
Работа с часовыми поясами и типичные ошибки смещения
Конвертация unix времени с учетом часовых поясов — это то, где спотыкается большинство разработчиков. Сам timestamp всегда UTC. Часовой пояс имеет значение только когда ты отображаешь или интерпретируешь этот timestamp для пользователя или записи в логах. Понимание этого различия предотвращает целую категорию багов.
Основы UTC
RFC 3339 определяет стандартный формат для представления UTC времени в тексте (2024-06-01T00:00:00Z). Когда ты конвертируешь Unix timestamp в читаемую строку, ты применяешь смещение часового пояса к UTC базе. Положительное смещение вроде +05:30 (время Индии) добавляет часы и минуты; отрицательное смещение вроде -05:00 (восточное время США) их вычитает.
Автоматическое определение часового пояса
Большинство современных языков и браузеров могут автоматически определить локальный часовой пояс. В JavaScript Intl.DateTimeFormat().resolvedOptions().timeZone возвращает имя IANA часового пояса (например, America/New_York). В Python модуль zoneinfo (Python 3.9+) работает с IANA зонами нативно. Полагаться на автоматическое определение нормально для отображения, но никогда не полагайся на него для хранения или вычисления timestamps.
Типичные ошибки смещения
- Трактовка локального времени как UTC: Если твой сервер настроен на
UTC+2и ты вызываешьdatetime.now()без указания часового пояса, ты получишь локальное время, которое выглядит как UTC, но отличается на два часа. - Переходы на летнее время (DST): Фиксированное смещение вроде
+01:00не учитывает DST. Используй именованные IANA зоны (Europe/Berlin) вместо фиксированных смещений, где это возможно. - Несоответствие миллисекунд и секунд: Передача timestamp в миллисекундах в функцию, ожидающую секунды, дает дату в году 55000+. Всегда сначала проверяй величину числа.
- Настройки часового пояса базы данных: MySQL и PostgreSQL могут хранить и отображать timestamps по-разному в зависимости от часового пояса сессии. Храни timestamps в UTC и конвертируй на уровне приложения.
Примеры кода: JavaScript, Python и SQL
Следующие фрагменты покрывают самые распространенные сценарии конвертации unix в дату. Каждый пример использует конкретный timestamp: 1717200000, который соответствует 1 июня 2024 года, 00:00:00 UTC.
JavaScript: конвертация Unix Timestamp
Объект Date в JavaScript работает в миллисекундах, поэтому сначала умножь timestamp в секундах на 1000.
// JavaScript конвертация unix timestamp в дату
const unixSeconds = 1717200000;
const date = new Date(unixSeconds * 1000); // конвертировать в миллисекунды
// UTC строка
console.log(date.toUTCString());
// Вывод: "Sat, 01 Jun 2024 00:00:00 GMT"
// Отображение в локальном часовом поясе (использует часовой пояс браузера/системы)
console.log(date.toLocaleString("ru-RU", { timeZone: "Europe/Moscow" }));
// Вывод: "01.06.2024, 03:00:00"
// Формат ISO 8601
console.log(date.toISOString());
// Вывод: "2024-06-01T00:00:00.000Z"
Обрати внимание, как один и тот же timestamp отображается как 3 утра по московскому времени, потому что полночь UTC — это 3 утра по московскому времени. Это не баг; это корректное поведение конвертации unix времени с часовыми поясами.
Python: Unix Timestamp в Datetime
Модуль datetime в Python предоставляет чистые, явные методы. Всегда используй timezone-aware объекты datetime в продакшн коде.
from datetime import datetime, timezone
from zoneinfo import ZoneInfo # Python 3.9+
unix_seconds = 1717200000
# Python unix timestamp в datetime (UTC)
dt_utc = datetime.fromtimestamp(unix_seconds, tz=timezone.utc)
print(dt_utc)
# Вывод: 2024-06-01 00:00:00+00:00
# Конвертация в конкретный часовой пояс
dt_moscow = dt_utc.astimezone(ZoneInfo("Europe/Moscow"))
print(dt_moscow)
# Вывод: 2024-06-01 03:00:00+03:00
# Форматирование в читаемую строку
print(dt_utc.strftime("%d %B %Y в %H:%M UTC"))
# Вывод: 01 June 2024 в 00:00 UTC
Использование datetime.fromtimestamp() без аргумента tz возвращает naive (без часового пояса) datetime в локальном системном времени, что может вызвать скрытые баги в серверных средах. Всегда передавай tz=timezone.utc как привычку.
SQL: эпоха в Datetime
И PostgreSQL, и MySQL поддерживают прямую конвертацию эпохи в datetime.
-- PostgreSQL: конвертация unix timestamp в дату
SELECT TO_TIMESTAMP(1717200000) AS converted_date;
-- Вывод: 2024-06-01 00:00:00+00
-- MySQL: конвертация unix в дату
SELECT FROM_UNIXTIME(1717200000) AS converted_date;
-- Вывод: 2024-06-01 00:00:00
-- Примечание: FROM_UNIXTIME использует часовой пояс сессии. Установи его явно:
SET time_zone = '+00:00';
SELECT FROM_UNIXTIME(1717200000);
Для более глубокого руководства по хранению и запросам timestamps в базах данных, смотри Unix Timestamps в базах данных: лучшие практики хранения и запросов.
Типичные случаи использования: эпоха в дату в реальных системах
Понимание механизмов — это одно. Видеть, как конвертация эпохи в дату работает в реальных системах, помогает это усвоить. Вот три конкретных сценария из типичных паттернов разработки SaaS.
Кейс: парсинг REST API, хранение в базе данных и логирование в бэкенде
Представь SaaS платформу аналитики, которая получает события из стороннего REST API. Каждый ответ API включает поле вроде "event_time": 1717200000. Вот как команда обрабатывает это на каждом уровне:
1. Парсинг REST API
Бэкенд сервис получает JSON payload и сразу валидирует единицу timestamp. Поскольку значение имеет 10 цифр, команда подтверждает, что это секунды (13 цифр указывали бы на миллисекунды). Python сервис конвертирует его в UTC-aware объект datetime перед любой дальнейшей обработкой. Это гарантирует, что последующие функции никогда случайно не получат сырое целое число.
2. Хранение в базе данных
Платформа хранит значение в PostgreSQL колонке типа TIMESTAMPTZ (timestamp с часовым поясом). Приложение всегда вставляет в UTC используя TO_TIMESTAMP(1717200000). Хранение в UTC означает, что когда компания расширится для обслуживания пользователей в разных регионах, никакой миграции данных не потребуется. Запросы всегда фильтруют в UTC и конвертируют в локальное время только на уровне представления.
3. Логирование в бэкенде
Пайплайн логирования прикрепляет ISO 8601 UTC строку (2024-06-01T00:00:00Z) к каждой записи лога вместе с сырым Unix timestamp. Этот двойной подход означает, что инженеры могут читать логи напрямую без инструмента конвертации, в то время как автоматизированные системы мониторинга все еще могут делать точную арифметику с целочисленными значениями. Когда приходит баг-репорт "ошибка произошла около 9 утра по токийскому времени", команда конвертирует это в диапазон Unix timestamp и запрашивает логи напрямую.
Этот трехуровневый паттерн (парсить, хранить в UTC, отображать локально) — самый чистый способ обработки конвертации времени в любой продакшн системе.
Быстрый совет: Если ты работаешь с Discord ботами или серверами сообществ, Unix timestamps также питают нативное форматирование времени Discord. Узнай как в нашем руководстве Как работают Discord Timestamps и как их использовать на твоем сервере.
Заключение
Конвертация Unix timestamp в читаемую дату проста, как только ты поймешь три правила: timestamp всегда UTC, единица измерения — либо секунды, либо миллисекунды (проверь перед конвертацией), и смещения часовых поясов применяются во время отображения, а не хранения. Независимо от того, пишешь ли ты на JavaScript, Python или SQL, встроенные инструменты надежны, если ты используешь их с явными аргументами часовых поясов. Применяй трехуровневый паттерн из кейса выше (парсить, хранить в UTC, отображать локально) и ты избежишь самых распространенных подводных камней в конвертации времени в любой SaaS системе.
Конвертируй любой Unix Timestamp мгновенно
Вставь любой timestamp и получи точную UTC дату, локальное время и разбивку часовых поясов в один клик. Без настройки, без регистрации.
Попробуй бесплатный конвертер на unixtimestamp.app →
Timestamp в секундах — это 10-значное число (для дат около 2026 года), в то время как timestamp в миллисекундах — 13 цифр. Объект Date в JavaScript нативно использует миллисекунды. Чтобы конвертировать timestamp в секундах в JavaScript, умножь на 1000 перед передачей в new Date(). Путаница этих двух единиц — самая частая причина кардинально неверных дат.
Это ожидаемое поведение, а не баг. Unix timestamp представляет UTC момент. Если полночь UTC приходится на предыдущий календарный день для твоего часового пояса (например, UTC 00:00 — это 21:00 по московскому времени предыдущего дня), отображаемая дата будет отличаться. Всегда указывай целевой часовой пояс явно при форматировании для отображения.
Используй datetime.fromtimestamp(ts, tz=timezone.utc) из модуля datetime. Это возвращает timezone-aware UTC объект datetime. Избегай вызова datetime.fromtimestamp() без аргумента tz, так как он использует локальный системный часовой пояс и создает naive datetime, который может вызвать скрытые ошибки в серверных средах.
Храни timestamps как TIMESTAMPTZ (PostgreSQL) или как UTC целые числа. Избегай хранения отформатированных строк вроде "1 июня 2024", потому что их сложнее запрашивать, сортировать и сравнивать. Конвертируй в читаемый формат только на уровне приложения или представления, сохраняя базу данных нейтральной к часовым поясам и портабельной.
Эпоха Unix 1 января 1970 года была выбрана ранними разработчиками Unix как удобная, недавняя точка отсчета. Это не было техническим требованием, а практическим решением, принятым в начале 1970-х годов, когда Unix разрабатывался в Bell Labs. Эта дата с тех пор стала универсальным стандартом для измерения компьютерного времени.