必须修改Dockerfile安装tzdata并配置时区文件，仅靠devcontainer.json设TZ环境变量无效；Alpine镜像默认无tzdata，需apk add tzdata后复制时区文件并删除包以保持精简，同时确保Node进程能读取/etc/localtime。
VSCode Dev Container 里 Node 进程时区还是 UTC？
默认 node 进程不读 TZ 环境变量，只认系统时区或显式传参。你在 devcontainer.json 里设了 "TZ": "Asia/Shanghai"，但 Node 启动后 new Date() 仍显示 UTC 时间，就是因为没生效。
必须在启动命令里显式注入 JVM 风格的时区参数——Node.js 虽不是 JVM，但很多运行时（如 node + moment、date-fns-tz）和底层 libc 依赖 tzdata 和 /etc/localtime，而 VSCode Dev Container 默认镜像（如 node:18-alpine）压根没装 tzdata，也未链接时区文件。
- 在
devcontainer.json的remoteEnv或容器启动命令中加TZ=Asia/Shanghai只影响 shell 层，不自动透传给 Node 子进程 - Alpine 镜像默认不含
tzdata包，/usr/share/zoneinfo/Asia/Shanghai根本不存在 - 即使你挂载了宿主机
/etc/localtime，Alpine 容器内 libc 仍可能 fallback 到 UTC（尤其 musl libc）
Dev Container 必须改 Dockerfile 才能真正生效
靠纯配置（devcontainer.json）无法解决底层时区缺失问题。必须在构建阶段把时区文件打进镜像，且确保 Node 进程能感知到。
以 node:18-alpine 为例，在 Dockerfile 中补全时区设置：
FROM node:18-alpine RUN apk add --no-cache tzdata \ && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ && echo "Asia/Shanghai" > /etc/timezone \ && apk del tzdata
然后在 devcontainer.json 中声明环境变量并指定启动用户（避免权限干扰时区文件读取）：
{
"image": "./Dockerfile",
"remoteEnv": { "TZ": "Asia/Shanghai" },
"runArgs": ["--user", "node"],
"customizations": {
"vscode": {
"settings": { "terminal.integrated.env.linux": { "TZ": "Asia/Shanghai" } }
}
}
}-
apk add tzdata是关键：Alpine 没这包，/etc/localtime就是空壳 -
apk del tzdata保持镜像精简，只留软链接和/etc/timezone -
--user node避免 root 用户下某些时区读取被绕过（musl libc 对非 root 用户更敏感）
K8S Pod 和 Dev Container 时区要对齐，别只改一边
本地 Dev Container 时区设对了，K8S 里 Pod 还是差 8 小时？说明两边没用同一套机制。硬编码 TZ=Asia/Shanghai 在 Dev Container 里，但在 K8S Deployment 里漏了对应配置，就会割裂。
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
Deployment YAML 必须同步加 env 字段，且值严格一致：
env: - name: TZ value: "Asia/Shanghai"
注意：value 必须带英文双引号，YAML 解析器对未加引号的 Asia/Shanghai 可能误判为特殊字符；同时确认你的镜像基础层（比如是否用了 Alpine）也已预装 tzdata，否则 K8S 里加了 TZ 也白搭。
- Java 应用还要额外加
-Duser.timezone=GMT+08，Node.js 不需要这个参数，但依赖底层 libc 和/etc/localtime - 如果用的是自定义镜像，检查
docker history <image>确认tzdata是否真被安装并清理 - K8S 中若用
PodPreset注入TZ，需确保该资源已启用且 selector 匹配你的 Pod label
验证时区是否真正生效，别信日志打印
光看 console.log(new Date()) 或 date 命令输出，容易误判。Node.js 的 Date 构造函数默认按本地时区解析字符串，但内部时间戳仍是 UTC，只是 toString() 做了格式化转换。
真正可靠的验证方式只有两个：
- 进容器执行
ls -l /etc/localtime，确认它指向/usr/share/zoneinfo/Asia/Shanghai - 运行
node -e "console.log(new Date().toLocaleString('zh-CN', {timeZone: 'Asia/Shanghai'}))"，看输出是否为当前北京时间（不是 UTC+8 计算值）
如果后者仍返回 UTC 时间，说明 tzdata 没生效或路径不对——这是最常被忽略的环节，也是所有“配置写了却无效”的根源。
