Docker容器时区不对，定时任务为什么会跑偏

容器里的定时任务跑错时间，现场看起来经常像业务 bug：报表提前生成、订单状态提前关闭、数据同步没赶上窗口期、日志按天切分乱了。实际排查到后面，发现不是 cron 写错，也不是代码逻辑错，而是容器时区还是 UTC。

最典型的场景是宿主机在 Asia/Shanghai，开发同事在代码里写了每天凌晨 2 点跑任务，结果线上容器实际按 UTC 跑，也就是北京时间上午 10 点才执行。反过来也有，业务以为是北京时间 0 点归档，容器里却按 UTC 0 点处理，直接提前 8 小时。

这个问题在 Docker 环境里很常见，因为容器不是完整虚拟机，它不会天然继承宿主机所有系统配置。镜像里有没有 tzdata、/etc/localtime 指向哪里、环境变量 TZ 有没有设置，都会影响容器里的时间表现。

先确认问题，不要上来就改 cron

实际使用中发现，很多人看到定时任务没按预期执行，第一反应是改 crontab 表达式，比如把 2 点改成 18 点，强行抵消 UTC 和北京时间的差值。这种改法短期能碰巧生效，但后面换镜像、换节点、上 Kubernetes，问题会更乱。

排查时先进容器看时间：docker exec -it container_name date

如果输出类似 Tue Jun 01 02:00:00 UTC 2026，而你期望的是 CST 或 +0800，那容器时区就没对上。

还可以看这两个位置：docker exec -it container_name cat /etc/timezone；docker exec -it container_name ls -l /etc/localtime

不同基础镜像结果不一样。Debian、Ubuntu 通常有 /etc/timezone，Alpine 默认可能很精简，CentOS/Rocky/AlmaLinux 的处理方式又不完全一样。

cron、应用进程、日志时间不一定看的是同一套东西

这里补充一点：容器里 date 显示对了，不代表所有程序都一定对。

Linux 系统时间本质上是内核提供的，容器和宿主机共享内核时间；时区是用户态解释时间的规则。date、cron、Java、PHP、Python、MySQL client、Nginx 日志，它们可能分别读取 /etc/localtime、TZ 环境变量、语言运行时参数、应用配置。

比如 Java 应用，有时系统 date 是 Asia/Shanghai，但 JVM 仍然可能因为启动参数、镜像配置、框架配置导致时区不一致。常见检查方式是看应用日志时间，再看 JVM 参数里有没有 -Duser.timezone=Asia/Shanghai。

PHP 也类似，php.ini 里的 date.timezone 如果没配，业务里 date() 出来的时间可能和预期不一致。Python 通常依赖系统时区或代码里的 timezone 设置。Node.js 多数情况下会参考 TZ，但容器内缺少时区数据库时，也会踩坑。

Docker运行时直接挂载宿主机时区文件

如果容器和宿主机要求同一个时区，最直接的办法是把宿主机时区文件挂进去。

docker run -d --name app -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro your-image

这种方式在传统 Docker 单机部署里很常见，优点是简单，容器里 date 基本马上就对。只读挂载也比较安全，不会让容器反过来改宿主机配置。

但它有一个前提：宿主机时区本身要正确。如果宿主机也是 UTC，而业务需要 Asia/Shanghai，那挂进去还是 UTC。还有一些系统没有 /etc/timezone，比如部分 CentOS 系发行版，这时挂 /etc/timezone 会报文件不存在，可以只挂 /etc/localtime。

多说一句，海外节点上这个坑更多。比如服务器在德国，宿主机被设置成 Europe/Berlin，业务却服务国内用户，容器跟着宿主机走就会出现夏令时切换问题。北京时间没有 DST，欧洲有 DST，到了切换日，定时任务差 1 小时这种问题非常隐蔽。

用TZ环境变量指定容器时区

更适合标准化部署的方式，是在容器启动时显式设置 TZ。

docker run -d --name app -e TZ=Asia/Shanghai your-image

docker-compose.yml 里通常这样写：environment: TZ=Asia/Shanghai

这个方式的好处是配置可见，不依赖宿主机当前时区。对于多地区部署，比如同一套镜像跑在香港、韩国、德国、美国节点上，业务时区可以通过环境变量控制。

注意，TZ 生效依赖镜像里有对应的时区数据库。很多精简镜像没有 tzdata，设置了 TZ 也可能没效果，或者只能影响一部分程序。

镜像里安装tzdata，把时区固定下来

如果定时任务属于业务强依赖，比如账单结算、游戏日常刷新、营销活动开始结束，建议在镜像构建阶段就把时区处理好，不要等运行时再碰运气。

Debian和Ubuntu镜像

Dockerfile 可以这样处理：

RUN apt-get update && apt-get install -y tzdata && ln -snf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo Asia/Shanghai > /etc/timezone && apt-get clean && rm -rf /var/lib/apt/lists/*

构建后进入容器执行 date，应该能看到 CST 或 +0800。

Alpine镜像

Alpine 更精简，很多线上镜像喜欢用它，但 timezone 经常就是这里漏掉。

RUN apk add --no-cache tzdata && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo Asia/Shanghai > /etc/timezone

如果后面为了减小镜像删除 tzdata，要注意部分语言运行时可能还需要时区数据库。只复制 /etc/localtime 能解决系统时间显示，但不是所有场景都稳。

CentOS、Rocky Linux、AlmaLinux镜像

这类镜像一般可以用：

RUN ln -snf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

如果镜像里没有对应 zoneinfo，再安装 tzdata：RUN yum install -y tzdata 或 RUN dnf install -y tzdata

容器里的crond也要重启

实际排障里遇到过一种情况：容器时区已经改了，date 也正常，但 crond 还是按旧时间跑。原因是 crond 启动时读取了环境或时区信息，后面改 /etc/localtime 不一定马上影响已经运行的 crond 进程。

解决方式很简单，改完时区后重启容器，或者重启 crond。

service cron restart，或者 /etc/init.d/cron restart，Alpine 里可能是 crond 进程，需要按镜像实际情况处理。

更推荐把时区写进镜像或启动参数，让容器启动时就是正确时区。不要进入容器手工 ln -sf，容器重建后这类改动会丢。

Kubernetes CronJob里更要显式处理

Kubernetes 里这个问题会再绕一层。CronJob 的 schedule 由 kube-controller-manager 解释，不完全等同于 Pod 容器里的 crond。

早期 Kubernetes 版本中，CronJob 默认按 controller-manager 所在时区解释，很多集群控制面是 UTC。新版本支持 .spec.timeZone，可以直接写 timeZone: Asia/Shanghai。

例如业务要求每天北京时间 02:30 执行，CronJob 可以配置 schedule: "30 2 * * *"，同时配置 timeZone: "Asia/Shanghai"。

但 Pod 里的应用时间仍然要单独保证。如果这个 Job 启动后用 Java 或 Python 处理“当天数据”，容器内时区不对，虽然调度时间对了，程序计算日期还是可能错。

这里最稳的做法是 CronJob 层设置 timeZone，容器层设置 TZ=Asia/Shanghai，镜像里安装 tzdata，应用层再按语言运行时确认一次。

业务跨地区部署时，不要让服务器所在地决定业务时区

很多业务部署在海外云服务器上，比如跨境电商、游戏出海、TikTok 相关业务、海外支付回调、全球 CDN 源站。服务器在德国，不代表业务就应该用 Europe/Berlin；服务器在韩国，也不代表所有任务都按 Asia/Seoul。

实际选择云服务器时，线路、带宽、DDoS 防护、IP 类型是网络维度，业务时区是应用维度，这两个不要混在一起。比如德国节点跑面向国内运营团队的电商后台，定时上架、报表结算可能仍然要按 Asia/Shanghai。

如果你也在找这种海外业务部署用的云服务器，可以看看129云。像德国双ISP-B型，4C 4G DDR4 ECC、60G SSD、50Mbps峰值带宽，适合电商、游戏、TikTok、Amazon 等场景；德国双ISP-C型是 4C 4G、70GB SSD、1Gbps带宽、GTT直连，线路更偏精品。需要韩国优化线路，也可以看韩国活动机型，4C 4G、30GB SSD、5Mbps、广播IP，适合轻量业务和区域测试。业务选型拿不准时可以直接打 400-9177118 问客服。

日志时间、数据库时间也要一起看

容器定时任务修好以后，别只盯着 cron 执行时间。日志和数据库时间经常是第二个坑。

Nginx access.log 默认按本地时间输出，如果容器时区从 UTC 改成 Asia/Shanghai，日志时间会变化。ELK、Loki、Prometheus 这类采集系统通常内部按 UTC 存储，前端展示再转换成本地时区。排障时要看清楚时间字段是 event time、ingest time 还是 display time。

数据库也一样。MySQL 有 system_time_zone、time_zone 两个变量。容器里应用按北京时间写入，数据库会话按 UTC 解释，查出来可能就差 8 小时。可以执行 SELECT @@global.time_zone, @@session.time_zone, @@system_time_zone; 看一下。

PostgreSQL 可以看 SHOW timezone;。如果业务使用 timestamp without time zone，应用层传什么就存什么；如果用 timestamp with time zone，显示和会话时区有关。这里不是说哪种类型固定更好，而是代码、数据库、报表工具必须按同一套约定处理。

常见修法的适用场景

宿主机时区可信、单机 Docker 部署：挂载 /etc/localtime 最快，启动参数加 -v /etc/localtime:/etc/localtime:ro。

镜像需要在多地区复用：用 TZ 环境变量，把 Asia/Shanghai、UTC、Europe/Berlin 这类配置交给部署环境。

定时任务强依赖日期计算：镜像安装 tzdata，Dockerfile 固化 /etc/localtime，同时应用启动参数里明确 timezone。

Kubernetes CronJob：使用 .spec.timeZone 控制调度时区，Pod 内继续设置 TZ 和 tzdata，不能只改其中一边。

微服务系统：建议统一约定内部存储用 UTC，展示层转换成本地时间；但运营类定时任务可以按业务时区调度，比如 Asia/Shanghai。这样日志检索、链路追踪、跨区分析会少很多歧义。

线上改动时的注意点

改容器时区看起来是小操作，但对定时任务来说可能等于改业务执行窗口。生产环境不要在临近整点、日切、结算窗口直接改。

比如原来容器 UTC，每天 18:00 UTC 执行，实际是北京时间次日 02:00。现在改成 Asia/Shanghai，如果 crontab 还是 18:00，那任务会变成北京时间 18:00 执行，业务窗口直接变了。正确做法是先确认 crontab 表达式代表的是哪个业务时间，再改容器时区和表达式。

还有一个细节：如果任务有补偿逻辑，比如“处理昨天数据”，时区改变当天要特别看日期边界。UTC 的昨天和北京时间的昨天，在 00:00 到 07:59 之间不是同一天。

改完后建议直接验证三类输出：容器内 date、定时任务日志时间、业务处理日期。比如任务日志里打印 now、today、yesterday、timezone，比只看 crond 是否启动更可靠。

可以直接照着排的命令

查看宿主机时间：date；timedatectl

查看容器时间：docker exec -it app date；docker exec -it app env | grep TZ

查看容器时区文件：docker exec -it app ls -l /etc/localtime；docker exec -it app cat /etc/timezone

临时启动测试容器：docker run --rm -e TZ=Asia/Shanghai alpine date

如果 Alpine 输出仍不符合预期，说明镜像没有 tzdata，可以测试：docker run --rm alpine sh -c "apk add --no-cache tzdata >/dev/null && TZ=Asia/Shanghai date"

查看 crontab：docker exec -it app crontab -l；如果是系统级任务，看 /etc/crontab 和 /etc/cron.d/。

重启容器让时区和 crond 同时重新加载：docker restart app

Docker Compose里常用写法

Compose 文件里可以这样写：environment 下加 TZ=Asia/Shanghai，同时按需挂载 /etc/localtime。

示例思路是：services.app.environment.TZ=Asia/Shanghai，volumes 里加 /etc/localtime:/etc/localtime:ro。

如果镜像是 Alpine、Debian slim、distroless 这类精简镜像，还是建议在 Dockerfile 阶段安装或复制时区数据。Compose 只能传环境变量，镜像里没有时区数据库时，效果会打折。

别把UTC当成错，也别把本地时区当成万能

UTC 本身不是错，很多基础设施都更喜欢 UTC，比如日志平台、监控系统、数据库内部存储、消息队列时间戳。错的是业务任务明明按北京时间设计，容器和应用却没人明确告诉它用哪个时区。

如果是全球业务，内部事件时间用 UTC 很正常；如果是运营动作、活动日切、账单结算，就要明确业务时区。容器里定时任务最怕“默认值”，因为默认值会随着镜像、宿主机、集群版本变化。

线上处理这类问题时，直接把时区写进部署规范：镜像是否包含 tzdata，容器环境变量 TZ 是什么，Kubernetes CronJob 是否配置 timeZone，应用运行时是否指定 timezone，日志和数据库按什么时区解释。