本文解析因夏令时（dst）切换导致 convert_tz 结果突变 1 小时的根本原因，结合 php 与 mysql 时区配置不一致问题，提供跨语言、可维护的时区统一实践方案。
本文解析因夏令时（dst）切换导致 convert_tz 结果突变 1 小时的根本原因，结合 php 与 mysql 时区配置不一致问题，提供跨语言、可维护的时区统一实践方案。
你遇到的现象——昨天 CONVERT_TZ(NOW(), 'UTC', '+10:30') 返回正确本地时间，今天却需改为 '+9:30' 才匹配——并非 MySQL Bug，而是时区偏移动态变化的真实体现。关键在于：'+10:30' 和 '+9:30' 是固定偏移量（offset）字符串，而 Asia/Colombo 等命名时区（named time zone）会自动适配夏令时规则。但印度标准时间（IST, UTC+5:30）全年无夏令时；你观察到的 ±1 小时变动，极大概率源于服务器所在时区（如美国东部时间 EST/EDT）或 MySQL 服务端配置受 DST 影响，而非 Colombo 本地。
? 根本原因定位
你的 PHP 代码使用了精准的命名时区：
$lastdatepost = new DateTime("now", new DateTimeZone('Asia/Colombo'));
$lastdatepost = $lastdatepost->format('Y-m-d H:i:s'); // ✅ 自动处理历史/未来所有时区规则而 SQL 中却硬编码了静态偏移：
CONVERT_TZ(NOW(), 'UTC', '+10:30') -- ❌ 假设“永远 UTC+10:30”，忽略 DST 变更
当 MySQL 服务器运行在启用 DST 的地区（例如美国东部时间，当前为 EDT=UTC-4），且其系统时区或 MySQL time_zone 变量未显式设为 'UTC' 或 'Asia/Colombo' 时，NOW() 返回的是服务器本地时间（已含 DST 偏移），再经 CONVERT_TZ 转换就会产生叠加误差。
✅ 验证方法：在 MySQL 中执行
SELECT NOW(), @@global.time_zone, @@session.time_zone; SELECT CONVERT_TZ(NOW(), '+00:00', 'Asia/Colombo'), CONVERT_TZ(UTC_TIMESTAMP(), '+00:00', 'Asia/Colombo');
✅ 推荐解决方案：全链路统一使用命名时区 + UTC 存储
1. MySQL 层：禁用硬编码偏移，改用命名时区
-- ✅ 正确：让 MySQL 自动查表计算 Asia/Colombo 的实时偏移（始终 UTC+5:30） SELECT CONVERT_TZ(UTC_TIMESTAMP(), '+00:00', 'Asia/Colombo'); -- ⚠️ 注意：首次使用命名时区前需加载时区表（InMotion Hosting 默认可能未加载） -- 登录 MySQL 后执行（需 SUPER 权限）： -- mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
2. PHP 层：保持现有逻辑，但确保与 MySQL 语义一致
// ✅ 继续使用命名时区（推荐）
$dt = new DateTime('now', new DateTimeZone('Asia/Colombo'));
$colomboTime = $dt->format('Y-m-d H:i:s');
// ✅ 或者：显式基于 UTC 构建（更清晰）
$utc = new DateTime('now', new DateTimeZone('UTC'));
$utc->setTimezone(new DateTimeZone('Asia/Colombo'));
$colomboTime = $utc->format('Y-m-d H:i:s');3. 关键架构建议：存储用 UTC，展示用本地时区
| 场景 | 推荐做法 |
|---|---|
| 数据库字段 | 定义为 DATETIME（非 TIMESTAMP），始终存 UTC 时间（如 UTC_TIMESTAMP()） |
| 写入 SQL | INSERT INTO logs (created_at) VALUES (UTC_TIMESTAMP()) |
| 读取展示 | 应用层（PHP）用 DateTimeZone('Asia/Colombo') 转换，不在 SQL 中做 CONVERT_TZ |
? 为什么？TIMESTAMP 类型会隐式触发时区转换，增加不可控性；而 DATETIME 是纯字面值，完全由应用层掌控时区逻辑，可测试、可审计、可迁移。
⚠️ InMotion Hosting 特别注意事项
- 其共享主机默认 time_zone 通常为 SYSTEM（即服务器系统时区，多为美国东部时间）。
- 不要依赖 NOW() 直接生成本地时间 —— 它反映的是服务器时间，不是你的业务时区。
- 若无法修改全局 time_zone，务必在每次连接后执行：
SET time_zone = '+00:00'; -- 强制会话使用 UTC，再通过 CONVERT_TZ 显式转换
总结：三步规避时区陷阱
- 杜绝硬编码 +HH:MM 偏移 → 改用 Asia/Colombo 等 IANA 时区名；
- 数据库只存 UTC → 写入用 UTC_TIMESTAMP()，读取在应用层转换；
- 验证环境一致性 → 检查 PHP date_default_timezone_set()、MySQL time_zone、服务器系统时区是否协同。
时区问题本质是时间语义的精确表达。用命名时区代替数字偏移，用 UTC 统一存储，让业务逻辑脱离服务器地理限制——这才是高可靠 Web 应用的时区管理基石。
