必须在navicat每个连接的「高级」页显式配置servertimezone，mysql需配对usetimezone=true并重输密码生效，postgresql需在initial statement中设set timezone；三方时区须同步验证。
必须在 Navicat 每个连接的「高级」页显式配置 serverTimezone，不能依赖系统时区或会话级 SET 语句。
MySQL 连接必须填对 serverTimezone 参数
Navicat 默认用本地系统时区发起连接，而跨国团队的开发机、测试服务器、云数据库可能分属 UTC、Asia/Shanghai、America/Los_Angeles 等不同环境，导致 TIMESTAMP 字段在同步时被错误转换成 NULL 或偏移 8 小时。
- 进连接属性 → 「高级」页 → 在「连接字符串」末尾追加：
&serverTimezone=Asia/Shanghai&useTimezone=true - 阿里云 RDS 或部分云环境需写成：
&serverTimezone=GMT%2B8&useTimezone=true（%2B是+的 URL 编码） - 只设
useTimezone=true不生效，必须配对serverTimezone - 改完要右键连接 → 「编辑连接」→ 重输密码，否则 Navicat 缓存旧握手信息，新参数不加载
PostgreSQL 连接不能靠 SET timezone 临时生效
SET timezone = 'Asia/Shanghai' 只作用于当前会话，每次新建查询窗口或同步任务都会重置。Navicat 不会继承上一次的手动设置。
- 进连接属性 → 「高级」页 → 在「Initial statement」栏填写：
SET timezone = 'Asia/Shanghai';（结尾分号不可少） - 这个语句会在每次建立连接后自动执行，比手动运行更稳定
- 别用
SHOW timezone验证——它返回的是 session 设置，可能被中间件覆盖；用SELECT now();对比客户端显示时间更准
同步前必须验证三方时区是否真正对齐
光配参数不等于生效。跨国场景下，源库、目标库、Navicat 客户端三者时区必须一致，否则预览和执行结果仍会出错。
- 连上源库后执行：
SELECT @@time_zone, NOW(), SYSDATE(); - 连上目标库后同样执行该语句
- 两个结果中的
NOW()应该落在同一小时区间（比如都是 2026-09-07 15:xx:xx），且@@time_zone显示为Asia/Shanghai或+08:00 - 如果源库是
SYSTEM（即系统时区），而服务器设的是 UTC，那即使 Navicat 配了Asia/Shanghai，也会因 MySQL 服务端解释逻辑不同而产生偏差
多人协作时最容易忽略的隐性陷阱
时区配置不是“设一次就永远 OK”的事。跨国团队里，每个成员的 Navicat 安装路径、版本、操作系统、甚至本地系统时间设置都可能不同，导致同一份同步任务在 A 机器上正常，在 B 机器上失败。
- 禁止共享 .nsx 同步文件而不同步连接配置——.nsx 只保存同步逻辑，不固化连接时区参数
- 所有连接必须统一命名规范，比如在连接名末尾标注时区：
prod-mysql-shanghai、staging-pg-utc - 在团队文档中明确记录每套环境的
serverTimezone值和验证 SQL，避免靠口头传递 - 同步日志里出现
Incorrect datetime value: 'NULL'或预览中created_at显示为空，基本可锁定为时区未对齐，不要先查表结构或权限
时区问题从来不是单点配置能解决的，它横跨客户端、驱动层、数据库服务端三层。跨国团队最常踩的坑，是以为配好 Navicat 就万事大吉，却忘了目标库的 @@global.time_zone 和 @@session.time_zone 也可能被运维脚本动态修改过。
