Navicat Premium 15 不自动处理 Excel 时区偏移，因其将日期视作无时区本地字符串解析；Excel 本身不存储时区，仅存序列数或文本，Navicat 依赖系统区域设置解释，若数据为 UTC 却未标注，导入 TIMESTAMP 字段时会因服务器时区（如 Asia/Shanghai）导致8小时偏差。
navicat premium 15 不会自动处理 excel 中的时区偏移，它把 excel 里的日期当成本地时间字符串解析，不带时区上下文。如果你的 excel 里存的是 utc 时间（比如 2026-06-02 15:30:00），而数据库字段是 timestamp 类型，且服务器时区是 asia/shanghai，那导入后实际存储值会变成 2026-06-02 15:30:00 +08:00 对应的本地等效时间——也就是多加了 8 小时，数据就错了。
Excel 里的时间到底有没有时区信息？
Excel 本身不存储时区。它只存一个“序列数”（如 45842.64583）或格式化后的文本（如 "2026/06/02 15:30"）。Navicat 读取时依赖底层 ODBC/Jet 驱动，驱动按系统区域设置解释这个字符串——比如 Windows 当前设为“中国标准时间”，它就默认按 GMT+8 解析，不会去查原始数据是否标了 Z 或 +00:00。
- 如果你的 Excel 数据来自 API 导出、日志导出或跨时区协作，大概率是 UTC 时间，但没标注
- Navicat 的「数据类型转换」里选
DATETIME或TIMESTAMP，只是告诉它“按日期逻辑转”，不是“按 UTC 转” - 即使你在 Navicat 连接属性里设置了
time_zone=+00:00，也只影响 SQL 查询时的会话时区，不影响导入阶段的字符串解析
导入前必须做的三件事
不能指望 Navicat 在导入时“猜对时区”。你得让数据本身具备可确定性：
- 在 Excel 里新增一列，用公式补全时区标识，例如：
=TEXT(A2,"yyyy-mm-dd hh:mm:ss")&" +00:00"（假设 A2 是原始 UTC 时间），生成类似"2026-06-02 15:30:00 +00:00"的文本 - 确保该列在 Navicat 导入时被映射到目标字段，并在「字段映射」界面点开该字段 → 勾选「数据类型转换」→ 类型选
TIMESTAMP→ 格式填yyyy-MM-dd HH:mm:ss Z（注意大小写和Z） - 确认目标数据库表字段类型是
TIMESTAMP（不是DATETIME），因为只有TIMESTAMP会根据连接时区做自动换算；DATETIME是纯字面值，存啥就是啥
为什么勾了“跳过错误记录”还卡在日期上？
日期解析失败（比如传了 "2026-06-02T15:30:00Z" 但格式模板写成 yyyy/MM/dd HH:mm:ss）属于「类型转换失败」，Navicat 默认把它当严重错误中断导入——哪怕你勾了「跳过错误的记录」和「继续导入其余记录」，它也不生效。
- 这类错误必须提前规避：格式模板必须严格匹配 Excel 列中实际字符串的样式（包括空格、T、Z、+00:00 等）
- 如果 Excel 里混着两种格式（如部分带
Z、部分不带），Navicat 无法智能 fallback，建议先用 Excel 的SUBSTITUTE或 Power Query 统一标准化 - 导入后务必查几条记录的
UNIX_TIMESTAMP()值，对比原始 UTC 秒数，验证是否偏移——这是唯一靠谱的校验方式
最易被忽略的一点：Navicat 的「高级」设置里所有日期格式模板都基于 Java SimpleDateFormat 规则，Z 表示 RFC 822 时区（如 +0800），X 才支持 Z 字面量（如 +00），而 XXX 支持 +00:00。如果你的 Excel 写的是 "2026-06-02 15:30:00 +00:00"，模板就得用 yyyy-MM-dd HH:mm:ss XXX，写成 Z 会直接报错。
