你的PHP项目中还在用时间戳么？
time()的最大范围是 1901 年 12 月 13 日 20:45:54 到 2038 年 1 月 19 日 03:14:07。
还有20年时间，这时候写项目还要用时间戳么？
如果一直用时间戳形式，到了2038年，有什么替代方案？
time()的最大范围是 1901 年 12 月 13 日 20:45:54 到 2038 年 1 月 19 日 03:14:07。
还有20年时间，这时候写项目还要用时间戳么？
如果一直用时间戳形式，到了2038年，有什么替代方案？
迷茫2017-04-10 16:23:57
这个是系统的事 ，是当时设计的32位达到了上限。
可以用64位。
也可以不用管，反正到时候你肯定不再写代码了，而且，20年的时间，你确定你的项目可以活那么久？
参考资料：
http://stackoverflow.com/questions/5826219/time-after-2038
http://stackoverflow.com/questions/2012589/php-mysql-year-2038-bug-what-is-it-how-to-solve-it
https://en.wikipedia.org/wiki/Year_2038_problem
PHPz2017-04-10 16:23:57
你们提问和回答之前有做过验证吗？仅仅只凭脑中一想就决定了php有2038bug？
～# date -s 2040/12/20
Thu Dec 20 00:00:00 CST 2040
～# php -r "echo time();"
2239545608
～# php -r "echo date('Ymd His;" time());
20401220 000015
当然，你们在32位的Windows xp上开发，你们活该low
巴扎黑2017-04-10 16:23:57
必须严肃的指明一个问题：由于可能处理未来的日期，所以2038问题在少部分应用中“到时解决”也已经晚了，必须提前应对。例如：万年历、时间戳计算、贷款计算等程序。
但是与C/C++/C#/Rust这样的静态类型语言不同，PHP对整形的类型限定是极弱的——PHP的整形仅仅等同于平台上的signed int，不支持unsigned，也不支持缩短取值范围（官方文档）。
因此对PHP程序本身而言，时间戳数字和相关的DateTime对象，能够无修改的迁移到64位从而解决2038年问题。
比较麻烦的是数据库部分。目前大致的状况是：
MySQL的TIMESTAMP使用int32，所以只支持到2038
MySQL的各种兼容实现，基本上有同样的问题
PgSQL的timestamp底层存储使用int64，上层卡一个公元1465001年的上限值
SQLite根本不提供日期类型，自己用bigint存就好了
简而言之：如果你确有立刻存储2038年以后时间戳的需求，请在MySQL中直接使用BIGINT。
