同一 SQL 查询在 PHP（CodeIgniter）与 phpMyAdmin/命令行中返回不同 end_date 值，本质是 MySQL 服务端时区与 PHP 应用层时区配置不一致，引发 DATETIME 或 TIMESTAMP 字段在读取/显示环节被隐式转换，尤其当字段值为 0000-00-00 00:00:00、NULL 或依赖函数（如 NOW()）生成时更易暴露该问题。
同一 sql 查询在 php（codeigniter）与 phpmyadmin/命令行中返回不同 `end_date` 值，本质是 mysql 服务端时区与 php 应用层时区配置不一致，引发 `datetime` 或 `timestamp` 字段在读取/显示环节被隐式转换，尤其当字段值为 `0000-00-00 00:00:00`、`null` 或依赖函数（如 `now()`）生成时更易暴露该问题。
这种“相同查询、不同结果”的现象，表面看是数据异常，实则是时区上下文错位引发的典型幻觉。你观察到 end_date 在 PHP 中每次刷新都变化（如变为当前时间），而其他客户端始终固定为 2022-12-31 23:59:59，这强烈指向一个关键线索：该字段并非静态存储的 DATETIME，而是由 MySQL 服务端时区感知型逻辑（如 TIMESTAMP 类型 + 默认值 CURRENT_TIMESTAMP 或触发器）动态生成或转换的值。
? 第一步：确认字段类型与默认行为
执行以下语句检查表结构：
SHOW CREATE TABLE rbs;
重点关注 end_date 字段定义。若其类型为 TIMESTAMP（而非 DATETIME），且带有 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，则它天然受 MySQL 服务端时区影响——TIMESTAMP 存储的是 UTC 时间戳，但查询时会根据当前会话时区自动转换为本地时间显示。
而 DATETIME 类型则严格按字面值存储和返回，不受时区影响。因此，若 end_date 是 TIMESTAMP，请继续排查时区配置；若是 DATETIME 却仍表现异常，则需检查是否存在：
- 触发器（
BEFORE SELECT不支持，但BEFORE UPDATE/INSERT可能间接影响） - 应用层 ORM/Query Builder 的自动时间填充（CodeIgniter 3.x 的
created_at/updated_at自动管理虽默认禁用，但若自定义了回调逻辑则可能介入） - MySQL 连接初始化语句中执行了
SET time_zone = ...
⚙️ 第二步：比对三处时区配置
| 环境 | 检查方式 | 示例命令/配置 |
|---|---|---|
| MySQL 服务端全局时区 | SELECT @@global.time_zone; |
SYSTEM（即系统时区）或具体值如 '+00:00'
|
| MySQL 当前会话时区 | SELECT @@session.time_zone; |
在 phpMyAdmin/CLI 中执行，应与服务端一致；在 PHP 中执行 mysqli_query($link, "SELECT @@session.time_zone") 查看实际值 |
| PHP 应用时区 |
date_default_timezone_get() 或 ini_get('date.timezone')
|
CodeIgniter 中通常在 application/config/config.php 设置 date_default_timezone_set('Asia/Shanghai')
|
⚠️ 关键陷阱：即使 @@global.time_zone 是 SYSTEM，Linux 系统时区（/etc/timezone 或 timedatectl status）与 PHP 的 date_default_timezone_set() 若不一致，会导致 TIMESTAMP 字段在 PHP 层解析时被错误转换。
✅ 第三步：强制统一会话时区（推荐方案）
在 CodeIgniter 数据库连接建立后，立即执行时区同步（推荐写入数据库配置或模型构造函数）：
// application/config/database.php 中的 $db['default'] 配置追加：
$db['default']['init_commands'] = [
'SET time_zone = "+08:00"' // 替换为你期望的 UTC 偏移，如上海为 +08:00
];
或在模型中手动设置：
$this->db->query("SET time_zone = '+08:00'");
$query = $this->db->get_where('rbs', ['rbs_id' => '92448']);
✅ 为什么有效？ 此命令强制当前数据库会话使用指定时区，确保
TIMESTAMP字段以统一基准解析，消除因会话时区差异导致的显示偏差。
? 验证与兜底建议
-
验证字段真实值：用
HEX()查看原始存储（排除显示层干扰）：SELECT rbs_id, HEX(end_date) AS end_date_hex FROM rbs WHERE rbs_id = '92448';
若返回
323032322D31322D33312032333A35393A3539（即2022-12-31 23:59:59的十六进制），说明数据本身正确，问题纯属时区转换。 避免
TIMESTAMP陷阱：生产环境建议将业务时间字段统一定义为DATETIME，并显式管理（如应用层赋值date('Y-m-d H:i:s')），彻底规避时区敏感性。CodeIgniter 特别注意：CI3.1.11 的 Query Builder 不会自动修改时间字段，但若启用了
encryption_key或自定义了post_execute回调，需排查是否意外注入了时间处理逻辑。
总结：这不是 Bug，而是 TIMESTAMP 类型的设计特性与多层时区配置未对齐的必然结果。通过 SET time_zone 统一会话时区，是最直接、零侵入的解决方案。务必优先验证字段类型——这是所有排查的起点。
