Yii 1.1.22 中时间字段存储类型由建表定义和模型读写逻辑共同决定，需通过改表结构、改模型逻辑、统一读写方式三步完成 DATETIME 与 BIGINT 时间戳切换，且须注意 MySQL TIMESTAMP 的 2038 年限制。
Yii 1.1.22 中，数据库字段用 DATETIME 还是时间戳（BIGINT）存时间，不是框架自动决定的，而是由你建表时定义、模型中如何读写共同决定的。它本身不提供“一键切换”功能，但可以通过明确的三步操作完成转换：改表结构、改模型逻辑、统一读写方式。
确认当前字段类型和使用场景
先查清你正在用的是哪种：
- 如果数据库字段是
DATETIME或TIMESTAMP类型，PHP 层拿到的是字符串（如"2024-05-20 14:30:00"），Yii 1.1 不会自动转成DateTime对象； - 如果字段是
BIGINT存 Unix 时间戳（秒级），那值就是整数，比如1716215400； - 注意：
TIMESTAMP在 MySQL 里有 2038 年上限，而DATETIME支持到 9999 年，长期系统推荐优先用DATETIME。
从 DATETIME 切换为时间戳（BIGINT）
适用于想统一用时间戳做计算、排序或对接其他系统的情况。分两步操作：
- 用 SQL 修改字段类型并迁移数据：
ALTER TABLE `usr_user_info` CHANGE `registerTime` `registerTime` BIGINT(20) NOT NULL;UPDATE `usr_user_info` SET `registerTime` = UNIX_TIMESTAMP(`registerTime`); - 在 Yii 模型中，重写
beforeSave()和属性赋值逻辑：
确保插入/更新时传入的是整数时间戳，而不是字符串；
可加验证规则：'registerTime', 'numerical', 'integerOnly'=>true； - 读取时若需转回可读时间，用 PHP 函数：
date('Y-m-d H:i:s', $model->registerTime)。
从时间戳（BIGINT）切回 DATETIME
更常见于修复历史设计缺陷，或需要支持跨时区显示、避免 2038 问题：
- SQL 修改字段：
ALTER TABLE `usr_user_info` CHANGE `registerTime` `registerTime` DATETIME NOT NULL;UPDATE `usr_user_info` SET `registerTime` = FROM_UNIXTIME(`registerTime`); - 模型中保持字段为字符串接收，或加 getter 封装转换：
public function getRegisterTimeFormatted() { return date('Y-m-d H:i:s', (int)$this->registerTime); }（若仍保留 BIGINT 字段）； - 若已改为 DATETIME 字段，则直接用：
$model->registerTime就是字符串，无需额外处理。
模型层时间字段的读写一致性建议
无论选哪种存储方式，都建议统一入口：
- 在
beforeSave()中强制格式化输入值，例如：
若前端传的是时间字符串，用strtotime()转为时间戳再存；
若存的是 DATETIME，用date('Y-m-d H:i:s', $ts)格式化后再赋值； - 避免在控制器里到处写
strtotime()或date()，把转换逻辑收拢到模型； - 查询条件中涉及时间范围时，统一用 MySQL 函数（如
BETWEEN FROM_UNIXTIME(?) AND FROM_UNIXTIME(?)）或 PHP 生成标准 DATETIME 字符串，别混用。
