接触php流行框架Laravel的时候，对这个框架的ORM能自动维护时间字段created_at和updated_at印象深刻，查看laravel 5.1源码，我们发现laravel采用了默认timestamp类型：Illuminate/Database 源码中 MYSQL 创建 Timestamp 类型字段代码。
那Laravel为什么不采用国内开发者比较喜欢的int类型或者时间范围更广的datetime类型呢？
引用zhuzhichao的说法：
比较了一下 datetime 和 timestamp：
datetime 更像日历上面的时间和你手表的时间的结合，就是指具体某个时间。
timestamp 更适合来记录时间，比如我在东八区时间现在是 2016-08-02 10:35:52， 你在岛国（此时时间为 2016-08-02 11:35:52），我和你在聊天，数据库记录了时间，发过去的信息带上的时间是你在1小时前的？ 好迷啊。当然有办法，自己计算时区。
时间范围是 timestamp 硬伤，当然 datetime 也记录不了刘备什么时候出生。
timestamp 和 UNIX timestamps
显示直观，出问题了便于排错，比好多很长的 int 数字好看多了。
int 是从1970年开始累加的，如果之前的时间需要用负数支持，数据库可能会有些问题，不过现在没什么问题了，timestamp 是自带时区转换的，同上面的第2项。
用户前端输入的时间一般都是日期类型，如果存储 int 还需要存前取后处理，UNIX timestamps 更快。
个人总结（仅供参考）：
timestamp 记录经常变化的更新/创建/发布/日志时间等，并且是近来的时间，够用，免时区处理，给你我便利；
datetime 记录生日、纪念事件、超出 timestamp 的时间，记得时区处理；
UNIX timestamps 是自己的喜好；
如果你不考虑时区，或者有自己一套的时区方案，随意了，喜欢哪个上哪个了；
laravel 是设计比较国际化的框架，为了程序员方便、符合数据库设计标准，所以 created_at updated_at 使用了 timestamp 是无可厚非的。
那么有没有一个时间类型同时解决了范围、时区的问题，这是不可能的！不是还有 tinyInt BigInt 吗？取自己所需，并且 MySQL 是允许数据库字段变更的。
关于 timestamp 的2038年问题：
如果到了2038年，MySQL官方还不解决这个问题的话，Laravel可以简单升级下，在model层就可以解决掉这个问题；当然，我相信MySQL会到时解决掉这个2038的问题，所以我们正常使用是没有问题的。
关于MYSQL数据库时间字段INT,TIMESTAMP,DATETIME性能效率比较：http://www.piaoyi.org/database/MYSQL-INT-TIMESTAMP-DATETIME.html
【参考】：
* 为什么 Laravel 默认使用timestamp字段作为新建时间，更新时间呢？