Timezone кажется мелочью ровно до первого инцидента. Сервис упал в 03:10. Мониторинг сработал в 00:10. В логах приложения ошибка в 05:10. А cron, который точно должен был запуститься ночью, вообще отработал не тогда. И начинается расследование не аварии, а вопроса: "чье это вообще время?" Проблема в том, что в инфраструктуре легко получить несколько разных временных реальностей:
• сервер живет в UTC;
• приложение пишет логи в локальном времени;
• контейнер использует другой timezone;
• база хранит timestamp без offset;
• мониторинг показывает время браузера;
• cron работает по системному времени хоста;
• разработчик смотрит все из своей локальной зоны.
•
В итоге события вроде бы относятся к одному инциденту, но на таймлайне разъезжаются на 2–3 часа.
▪️ Проверить timezone на Linux:
timedatectl
Посмотреть текущую дату с зоной:
date
Проверить UTC:
date -u
Для systemd-журнала удобно явно указывать временное окно:
journalctl --since "2026-05-29 03:00" --until "2026-05-29 03:30"
Но важно понимать: это окно интерпретируется в локальном времени системы, с которой вы работаете.
С cron тоже есть нюанс. Если на сервере стоит Europe/Moscow, то запись:
0 3 * * * /opt/scripts/backup.sh
запустится в 03:00 по времени этого сервера.
Если такой же cron стоит на другом сервере в UTC, задача фактически поедет на несколько часов.
▪️ Что помогает не страдать:
• хранить серверное время в UTC;
• писать логи с timezone или offset;
• использовать ISO 8601 формат;
• не хранить timestamp без понимания зоны;
• явно документировать, в каком времени работает cron;
• синхронизировать время через NTP;
• при расследовании сразу строить единый таймлайн.
▪️ Хороший timestamp выглядит примерно так:
2026-05-29T03:10:42Z
# или так:
2026-05-29T06:10:42+03:00
🤩 Плохой timestamp:
2026-05-29 03:10:42
Потому что без timezone непонятно, это UTC, Москва, Хельсинки, время контейнера или фантазия приложения.
#linux #timezone
🧑💻 NetworkAdmin