MySQL连接时必须显式设置时区，因TIMESTAMP按连接时区隐式转换而DATETIME不转换；需在连接字符串中指定time_zone='+08:00'或'Asia/Shanghai'，并严格区分二者语义与用法。
MySQL连接时必须显式设置时区，不能依赖系统默认
MySQL的TIMESTAMP列会自动按连接时区做隐式转换，而DATETIME不转换——但很多人误以为只要设了time_zone全局变量就一劳永逸。实际中，客户端连接建立时的time_zone会覆盖全局值，且不同驱动（如Python的pymysql、Java的mysql-connector-java）默认行为不一致。
常见错误现象：SELECT NOW()返回时间正确，但插入TIMESTAMP后查出来差8小时；或应用层写入“2024-01-01 12:00:00”，数据库存的是“2024-01-01 04:00:00”（UTC）。
- 连接字符串中强制指定
time_zone='+08:00'（MySQL 5.7+）或time_zone='Asia/Shanghai'（需服务器启用了时区表） - 避免用
SET time_zone = SYSTEM或SET time_zone = '+00:00'临时切换，这容易被后续语句覆盖 - 验证方式：
SELECT @@session.time_zone, @@global.time_zone;，确保前者是你期望的值
建表时明确区分DATETIME和TIMESTAMP的语义用途
TIMESTAMP本质是带时区的Unix时间戳（范围1970–2038），DATETIME是纯日期时间（范围1000–9999），二者物理存储和行为完全不同。混用会导致逻辑混乱，比如用TIMESTAMP存生日，结果2038年后自动变NULL。
- 存“事件发生时间”且需跨时区统一比较 → 用
TIMESTAMP，但必须保证所有客户端统一时区（推荐UTC） - 存“业务约定时间”如会议开始时间、订单发货时间 → 用
DATETIME，它不转换，所见即所得 - 禁止对
TIMESTAMP列使用DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP后还手动写入非UTC时间字符串
应用层读写必须与列类型严格对齐
ORM或驱动常自动做时区转换，比如Django默认把datetime对象转为UTC再发给MySQL，而MySQL又按连接时区二次转换——双重转换导致偏移加倍。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
典型错误：Python中用datetime(2024,1,1,12,0,0)（无tzinfo）写入TIMESTAMP列，驱动按本地时区解释为“东八区中午”，MySQL却按连接时区+00:00存成UTC，最终查出来变成“2024-01-01 04:00:00”。
- 写
TIMESTAMP前，确保值已是UTC（如dt.astimezone(timezone.utc)）或明确带+08:00偏移 - 写
DATETIME前，确保值不含时区信息，或显式剥离（dt.replace(tzinfo=None)） - 读取时，根据列类型决定是否补时区：读
TIMESTAMP结果应视为UTC时间，读DATETIME结果就是字面时间
mysqld启动参数和配置文件中的time_zone设置不可信
my.cnf里设default-time-zone='+08:00'只影响新连接的默认值，但很多运维脚本或监控工具会执行SET time_zone=SYSTEM，立刻覆盖它。更糟的是，MySQL 8.0之前default-time-zone不支持Asia/Shanghai这种命名时区，只能用偏移量。
- 不要在
my.cnf里设default-time-zone，改用连接层控制——更可控、可审计 - 检查是否有定时任务或DBA脚本执行
SET GLOBAL time_zone = ...，这种操作会影响所有新连接，但已有连接不变，造成混杂状态 - 生产环境建议统一用
+00:00作为连接时区，应用层负责UTC ↔ 本地时间转换，避免数据库成为时区逻辑中心
最麻烦的不是配置本身，而是时区逻辑分散在MySQL配置、连接字符串、ORM设置、应用代码多个地方，任何一处没对齐就会出错。盯住@@session.time_zone和你写入/读取的具体值，比背理论管用。
