你的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年，有什么替代方案？

不需要担心，到时候官方会升级PHP版本解决

这个是系统的事 ，是当时设计的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

你们提问和回答之前有做过验证吗？仅仅只凭脑中一想就决定了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

必须严肃的指明一个问题：由于可能处理未来的日期，所以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。

long够用么？php的时间戳我记得是没毫秒部分的

还在使用时间戳 别的我不知道眼前的需求当然是眼前的方法来满足和实现

ISO 8601

20年你的项目已经老掉牙了 所以不用担心 PHP版本更新下这问题就解决了

让人想起了当年的千年虫问题

请使用DateTime类来处理

想想有次做个项目，我判断如果超过了2025年，后面的逻辑就失效了，反正到时候这个项目肯定活不了那么久，就好笑。

32位MySQL也是可以使用bigint类型存储64位整数的,再不放心,你可以用varchar嘛.时间戳字段类型用bigint,64位整型最大值(2^64)/2-1=9223372036854775807足够了.服务器用64位Linux,这时PHP_INT_MAX的最大值也为(2^64)/2-1=9223372036854775807.

那个时候代码肯定不时我维护，啊哈哈哈

那个时候 = = 我不知道还写不写代码。。。。