Docker容器默认不自动同步宿主机系统时间，需主动配置时区：推荐挂载/etc/localtime和/etc/timezone只读文件，并设置TZ环境变量，确保容器内时间显示与时区解析与宿主机一致。
Docker 容器默认不自动同步宿主机的系统时间，因为容器拥有独立的用户空间和时区配置。所谓“自动同步”，本质是让容器内的时间显示、时区设置与宿主机保持一致——这需要主动配置，而非开箱即用。核心目标不是同步硬件时钟（那是 NTP 的事），而是确保容器读取和解释时间的方式与宿主机一致。
挂载宿主机时区文件（最常用、最可靠）
这是生产环境首选方式，直接复用宿主机的时区定义，实时生效且无需重启容器（挂载后立即生效）：
-
/etc/localtime是 Linux 系统识别当前时区的核心文件，通常为指向/usr/share/zoneinfo/Asia/Shanghai的软链接 -
/etc/timezone在部分发行版（如 Debian/Ubuntu）中用于记录时区名称，辅助系统工具识别
启动容器时添加这两个只读挂载：
docker run -d \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/timezone:/etc/timezone:ro \ --name myapp myimage:latest
Docker Compose 中写法：
services:
app:
image: myimage:latest
volumes:
- /etc/localtime:/etc/localtime:ro
- /etc/timezone:/etc/timezone:ro✅ 优点：简单、兼容性强、实时同步、不依赖镜像内部是否安装 tzdata
⚠️ 注意：宿主机自身时区必须已正确设置（可用 timedatectl status 验证）
同时设置 TZ 环境变量（增强兼容性）
某些应用（尤其是 Java、Node.js 等）优先读取 TZ 环境变量而非系统文件。单独设 TZ 可能被基础镜像忽略（如 Alpine 默认无 tzdata），但配合挂载使用能覆盖更多场景：
docker run -d \ -e TZ=Asia/Shanghai \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/timezone:/etc/timezone:ro \ myimage:latest
这个组合相当于双重保险：
- 文件挂载确保
date、cron、C 库等底层行为一致 -
TZ环境变量确保上层应用（如 Spring Boot、Pythondatetime）也能正确解析时区
构建镜像时固化时区（适合标准化交付）
如果镜像需跨环境部署（如测试/生产时区不同），可在 Dockerfile 中预设时区，并安装必要支持包：
FROM ubuntu:22.04
ENV TZ=Asia/Shanghai
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && \
echo $TZ > /etc/timezone && \
apt-get update && apt-get install -y tzdata✅ 优点：镜像自带时区，不依赖宿主机配置
❌ 缺点：修改时区需重建镜像；多区域部署时灵活性差
不推荐的做法
-
在容器内运行
ntpd或chronyd：容器不是完整 OS，不应承担系统级时间同步职责；宿主机应负责 NTP 校时，容器只需正确解释时间 -
仅靠
--init参数：docker run --init解决的是僵尸进程问题，对时区无影响 -
docker cp /etc/localtime复制后重启容器：操作繁琐、不可自动化，且无法响应宿主机时区变更
关键逻辑很清晰：
- 宿主机时间本身由 NTP 保证准确（这是前提）
- 容器只需“正确理解”这个时间——靠挂载
/etc/localtime+ 设置TZ就足够 - 所有方法都围绕“让容器用宿主机的时区定义”，而不是让容器自己去校时
不复杂但容易忽略
