Ошибки и коды · Инструкция
Часовой пояс Docker: TZ, tzdata и UTC
Проблема «неправильного времени» бывает двух типов: системные часы контейнера синхронизированы с хостом, но форматируется неверная timezone, либо само приложение игнорирует системную зону и использует собственную.
Короткий ответ
Для серверных сервисов предпочтительно хранить время в UTC. Если приложению нужен локальный пояс, задайте валидную IANA-зону и убедитесь, что образ содержит.
Что важно понять до начала
Контейнер не имеет отдельного аппаратного времени: процессы видят системное время ядра хоста. Отображаемая локальная дата зависит от timezone data и настроек приложения. Минимальные образы могут не содержать пакет tzdata. Для логов и распределённых систем UTC обычно уменьшает неоднозначность DST и корреляции событий.
Совет: Практический ориентир: Нет. Обычно часы приходят от ядра хоста; настраивается именно timezone представления времени.
Пошаговый порядок действий
- 1. Сравните `date -u` и локальный `date` внутри контейнера.
- 2. Проверьте, установлен ли tzdata и существует ли нужная IANA-зона, например `Europe/Berlin`.
- 3. Если локальная зона действительно нужна, передайте `TZ` или настройте её способом, поддержанным вашим образом.
- 4. Перезапустите процесс и проверьте логи на границе даты и в приложении.
- 5. Для БД и API отдельно уточните timezone настройки самого приложения/драйвера.
Важно: Критично для этой задачи: Не монтируйте `/etc/localtime` с хоста вслепую в переносимый образ: это связывает поведение контейнера с конкретным хостом и не решает настройки приложения.
Ошибки и пограничные случаи
Не монтируйте `/etc/localtime` с хоста вслепую в переносимый образ: это связывает поведение контейнера с конкретным хостом и не решает настройки приложения. При переходе на летнее/зимнее время используйте именованную IANA-зону, а не фиксированное смещение вроде `UTC+2`, иначе сезонный переход не будет учтён корректно.
Предупреждение: Пограничный случай: Для серверных логов чаще удобнее UTC: проще сопоставлять события между регионами и избегать неоднозначности DST.
Проверка перед завершением
- Сравните `date -u` и локальный `date` внутри контейнера.
- Если локальная зона действительно нужна, передайте `TZ` или настройте её способом, поддержанным вашим образом.
- Для БД и API отдельно уточните timezone настройки самого приложения/драйвера.
- Проверено отдельно: Нет. Обычно часы приходят от ядра хоста; настраивается именно timezone представления времени.
Практический сценарий и контроль результата
Если задача — единообразные серверные логи, UTC обычно проще локального времени: события из разных регионов сопоставляются без двусмысленности переходов DST. Локальную IANA‑зону задавайте только там, где она нужна пользователю или бизнес‑правилам. Если переменная TZ не меняет отображение, проверьте наличие timezone data в минимальном образе и настройки самого приложения. Не путайте системные часы с форматированием даты: контейнер обычно видит время ядра хоста, а зона меняет представление.
Дополнительные нюансы и проверка
Если пользователи видят правильное время, а логи всё ещё смещены, проверьте настройки логгера или фреймворка: приложение может принудительно форматировать timestamps в UTC. Обратная ситуация тоже возможна — системная зона изменена, а база данных хранит timestamps без зоны. Поэтому тестируйте один конкретный timestamp от создания до отображения. На границе перехода летнего времени именованная зона даёт корректные сезонные правила, тогда как фиксированное смещение их не знает.
Что учитывать
Контейнер не имеет отдельного аппаратного времени: процессы видят системное время ядра хоста. Отображаемая локальная дата зависит от timezone data и настроек приложения. Минимальные образы могут не содержать пакет tzdata. Для логов и распределённых систем UTC обычно уменьшает неоднозначность DST и корреляции событий.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. docker container run). Пример и формулировки — редакция N1RO на 2026-09-22.