Timestamp и часовые пояса: почему логи «врут» на несколько часов

Логи «врут» на несколько часов чаще из‑за часового пояса, а не из‑за «сломанного» timestamp. Одно и то же unix-число означает один момент на оси UTC. На экране оно превращается в стенные часы сервера, ноутбука аналитика или настройки дашборда. Если сервер пишет UTC, а вы читаете «как в Москве» без сдвига, событие уезжает на три часа зимой и на другие смещения в зависимости от правил зоны. Как перевести само число в дату — в unix timestamp в дату. Здесь разбор расхождений: UTC против локали, летнее время, двойная конвертация и проверка в конвертере даты и unix-времени. Ниже: откуда берётся сдвиг, как читать журналы команды, что проверить в коде и как не склеить два перевода подряд.

Почему одно число даёт разные «часы на стене»

Unix timestamp хранит момент, не «цифры на кухонных часах». Момент общий. Отображение зависит от зоны: UTC, Europe/Moscow, America/New_York и так далее. Два человека с одним числом из лога честно видят разное локальное время — и оба правы относительно своих часов.

Путаница начинается, когда в чате пишут «у меня 18:00», не уточняя зону. Коллега в другой зоне ищет строку лога около своих 18:00 и не находит инцидент. Инцидент был в 18:00 UTC или в 18:00 по Москве — это разные моменты.

Сервер приложения, балансировщик и ноутбук разработчика часто настроены по-разному. Строка без указания зоны выглядит «как местная», хотя внутри лежит UTC. Глаз читает часы, мозг подставляет свой город.

UTC в логах — норма, не баг

Многие команды пишут журналы в UTC специально: так проще стыковать сервисы в разных регионах. «Враньё» появляется только при чтении без перевода в вашу зону. Сверьте число в конвертере: посмотрите UTC и локаль рядом.

Если в логе уже стоит текстовая дата с суффиксом Z или +00:00, это UTC. Суффикс +03:00 — смещение от UTC. Без суффикса считайте формат подозрительным, пока не проверите конфиг логгера.

Летнее время и «лишний» час

Зоны вроде America/New_York дважды в год меняют смещение. Событие «в то же гражданское время» год назад может лежать под другим offset. Сравнивать инциденты по «просто вычесть три часа» опасно.

Для России правила зон тоже менялись исторически. Для свежих логов обычно достаточно актуальной зоны Europe/Moscow. Для архивов за старые годы уточняйте, какое смещение действовало тогда.

Типичные сценарии, где логи расходятся

Аналитик выгружает CSV с колонкой unix-секунд. Excel на машине показывает локаль. Коллега в другом городе открывает тот же файл и видит другие часы. Число в ячейке одно, подпись разная.

Дашборд в Grafana «в UTC», алерт в мессенджере «по Москве», текст ошибки в Sentry «по времени контейнера». Три экрана — три подписи одного момента. Без общей договорённости постмортем превращается в спор о часах.

Мобильный клиент шлёт created_at в локали устройства, API хранит UTC, отчёт строится в зоне заказчика. Цепочка из трёх преобразований даёт сдвиг, если одно звено уже сдвинуло значение.

Двойная конвертация

Ошибка: взять локальную строку, перевести в timestamp «как UTC», потом снова показать как локаль. Часы уезжают на величину смещения. Лечится так: храните момент в UTC (или в timestamp), а зону применяйте один раз на отображении.

В коде избегайте парсить дату без зоны так, будто это UTC, если пользователь ввёл «своё» время. Либо требуйте зону явно, либо документируйте, какая зона принята по умолчанию.

Секунды, миллисекунды и «сдвиг на часы»

Иногда «сдвиг» на самом деле ошибка длины числа: миллисекунды прочитали как секунды или наоборот. Тогда дата улетает в 1970-е или в далёкое будущее. Это не пояс, а масштаб. Разбор числа: unix timestamp в дату.

Если дата «почти сейчас», но часы мимо — смотрите пояс. Если год безумный — сначала длину числа, потом пояс.

Как сверять метку на Тулси и в команде

Скопируйте число из лога. Откройте конвертер даты и unix-времени. Режим число → дата. Сравните блок UTC и локальное время вашего устройства.

Запишите в тикет оба: «момент UTC … / у нас на стенах …». Так следующий дежурный не повторит спор. Если в логе уже ISO-строка, всё равно прогоните через инструмент спорный фрагмент.

Договоритесь в команде: журналы пишем в UTC; в чатах инцидент указываем с зоной; дашборды подписываем. Одна страница правил экономит час на каждом разборе.

Что проверить в конфиге

Часовой пояс контейнера (TZ), настройки СУБД (timezone), формат логгера, зона в BI-инструменте. Часто «врёт» не timestamp, а последний слой отображения.

Проверьте, не округляет ли система до минут и не подменяет ли «сейчас» временем деплоя. Редкие баги маскируются под сдвиг пояса.

Мини-чеклист дежурного

Есть ли в строке Z или смещение? Совпадает ли длина числа с секундами или миллисекундами? Что показывает конвертер в UTC? Какая зона у дашборда? Только после этих четырёх вопросов меняйте код «наугад».

Если нужно просто понять дату из числа без разбора зон — вам сюда: unix timestamp в дату. Если дата «правильная», а часы спорные — оставайтесь в этой статье.

Политика времени для продукта

Храните моменты в UTC или в unix-времени. Отдавайте клиенту ISO с явным смещением или с Z. Показывайте пользователю время в его зоне на уровне интерфейса.

В отчётах для бухгалтерии и смен фиксируйте зону в шапке файла. Иначе через год никто не вспомнит, «чьи» это были 18:00.

Не смешивайте в одной колонке строки с зоной и без неё. Лучше две колонки: момент UTC и подпись локали для человека.

Смежные материалы

Перевод числа в дату и путаница секунд с миллисекундами: unix timestamp в дату. Практика сверки: конвертер.

Эта статья про пояса и сдвиги «на несколько часов». Если год в ответе неверный — сначала проверьте длину timestamp в соседнем материале.

Частые вопросы

Почему в логе одно время, а на часах другое?

Чаще всего лог в UTC или в зоне сервера, а вы смотрите локальные часы. Момент один, подписи разные. Вставьте число в конвертер и сравните UTC с вашей зоной. Уточните в чате, какую зону имеет в виду коллега.

Чем эта тема отличается от «unix timestamp в дату»?

Там — как из числа получить календарную дату и не перепутать секунды с миллисекундами. Здесь — почему при «правильной» дате часы всё равно расходятся из‑за поясов и двойного перевода. Оба навыка нужны дежурному. Ссылка на базовый перевод: unix timestamp в дату.

Нужно ли всегда писать логи в UTC?

Для распределённых систем это привычная и удобная норма. Главное — единый правило и явная подпись. Если вся команда в одной зоне и сервер один, локаль тоже может работать, пока вы не начнёте стыковать внешние сервисы. Документируйте выбор.

Как понять, что сдвиг именно на три часа из‑за Москвы?

Сверьте то же число в UTC и в Europe/Moscow на конвертере. Если разница совпадает с текущим смещением зоны, это пояс, а не порча данных. Если разница другая — ищите второе преобразование или ошибку формата.

Что делать с летним временем в других странах?

Не вычитайте «фиксированные N часов» из головы на годы вперёд. Используйте именованную зону и библиотеку с актуальными правилами. Для разовой проверки смотрите UTC и локаль в инструменте. В коде храните момент, а не «строку после ручного сдвига».

Может ли база хранить timestamp без зоны и путать всех?

Да. Тип «timestamp without time zone» часто означает «наивные» часы. При чтении драйвер подставляет зону сессии. Проверьте timezone сессии и документы СУБД. Надёжнее хранить момент с зоной или unix-значение и форматировать при выдаче.

Почему мобильное приложение «вриёт» сильнее веба?

Устройство пользователя гуляет по зонам в роуминге. Если клиент шлёт локальную строку без смещения, сервер может принять её как UTC. Требуйте ISO со смещением или отправляйте unix-время. Тогда отображение снова станет задачей интерфейса.

Как писать время инцидента в тикете?

Укажите момент в UTC и локаль команды в скобках. Добавьте исходное число из лога. Так любой дежурный воспроизведёт сверку в конвертере. Одна строка экономит споры в чате.

Округление до минуты влияет на «сдвиг»?

Иногда кажется, что время «поплыло», хотя просто обрезали секунды. Сверяйте полную метку. Для поиска в логах расширяйте окно на минуту–две. Не путайте округление с часовым поясом.

Где сверить спорный лог прямо сейчас?

Откройте конвертер даты и unix-времени, вставьте число или строку. Для базового перевода числа в дату читайте unix timestamp в дату. Зафиксируйте UTC и вашу зону в тикете до правки кода.

Когда часы в журнале спорят с вашим городом, откройте конвертер и сравните UTC с локалью. Базовый разбор числа: unix timestamp в дату. В команде зафиксируйте, в какой зоне пишете логи и как подписываете инциденты.