Docker 部署后文章发布时间变成 UTC 的排查与修复

最近在 Docker 部署 YESCMS，并使用 PostgreSQL 数据库时，发现后台发布文章后的时间不对：页面显示出来的时间像是按 UTC 来算的，比本地时间少了 8 个小时。

这个问题看起来像数据库时区问题，但真正排查下来，根因在容器运行环境。

现象

本地开发环境发布文章，时间正常。

部署到 Docker 后，发布文章的时间会偏向 UTC。例如北京时间下午发布，页面上显示出来却像是早上。

项目里的文章发布时间使用的是类似这样的写法：

create_time = DateTime.Now,
update_time = DateTime.Now,

这段代码本身没有做 UTC 转换。它取的是当前运行环境的本地时间。

根因

Docker 容器默认时区通常是 UTC。

所以问题不是 PostgreSQL 主动把时间改成了 UTC，也不是页面展示时强行转换了时区，而是应用运行在容器里时，DateTime.Now 拿到的“本地时间”本来就是 UTC。

换句话说：

DateTime.Now 取的是容器时间
容器默认是 UTC
所以写入数据库的时间就是 UTC 风格的时间

PostgreSQL 里如果字段使用 timestamp without time zone，它只是存储一个日期时间值，不会替你记住这个值到底属于哪个时区。应用写进去什么，它就保存什么。

不建议到处改业务代码

遇到这个问题，最直接的反应可能是把代码改成：

DateTime.UtcNow.AddHours(8)

这不推荐。

原因很简单：这会把“中国时区”硬编码进业务代码。以后如果部署到其它地区，或者同一个镜像给不同地区使用，就会继续产生新的时间问题。

更好的做法是让运行环境告诉应用：当前部署到底使用哪个时区。

推荐修复方式

在 docker-compose.yml 里给应用容器加上 TZ 环境变量：

services:
  yescms:
    environment:
      ASPNETCORE_ENVIRONMENT: Production
      ASPNETCORE_URLS: http://+:8080
      TZ: Asia/Shanghai

这样处理后，容器内的本地时间会按 Asia/Shanghai 计算，DateTime.Now 获取到的就是北京时间。

如果以后部署到其它地区，只需要改 compose 里的 TZ：

TZ: America/Los_Angeles

不需要重新改代码，也不需要把 Docker 镜像固定成某个国家或地区的时区。

为什么不直接写进 Dockerfile

也可以在 Dockerfile 里设置：

ENV TZ=Asia/Shanghai

但这样会让镜像默认固定为中国时区。

如果这个镜像只在中国服务器上运行，问题不大；但如果以后镜像可能部署到国外服务器，固定在 Dockerfile 里就不够灵活。

所以更稳妥的做法是：

镜像保持通用
部署环境通过 docker-compose.yml 指定时区

这也是配置和镜像职责分离的做法。

修改后如何生效

修改 docker-compose.yml 后，需要重建或重启容器：

docker compose up -d --build

如果使用的是远程镜像，且没有重新构建镜像，也可以直接重建容器：

docker compose up -d

然后进入容器检查时间：

docker exec -it yescms date

如果输出的是北京时间，说明容器时区已经生效。

旧文章时间怎么办

这个修复只影响后续新写入的数据。

已经写入数据库的旧文章时间不会自动修正。因为数据库里保存的是一个普通日期时间值，系统无法可靠判断哪些记录是 UTC 写入、哪些记录本来就是正确时间。

如果确定某一批旧数据全部都是 UTC 错误时间，可以在备份数据库后，单独写 SQL 批量加 8 小时。但这个操作会直接修改历史数据，应该先确认范围，再执行。

总结

Docker 部署后文章发布时间显示成 UTC，本质上是容器默认时区导致的。

对于使用 DateTime.Now 的应用，最简单、最稳的修复方式是在部署层指定时区：

TZ: Asia/Shanghai

不要把时区补偿写死到业务代码里，也不要轻易把通用镜像固定成某一个地区的时区。把时区放在 compose 配置里，既能解决当前问题，也方便以后迁移到其它地区部署。