你的PHP项目中还在用时间戳么?
PHP中文网
PHP中文网 2017-04-10 16:21:57
0
14
1095

time()的最大范围是 1901 年 12 月 13 日 20:45:54 到 2038 年 1 月 19 日 03:14:07。

还有20年时间,这时候写项目还要用时间戳么?

如果一直用时间戳形式,到了2038年,有什么替代方案?

PHP中文网
PHP中文网

认证高级PHP讲师

reply all(14)
阿神

不需要担心,到时候官方会升级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

PHPzhong

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

Peter_Zhu

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

阿神

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

阿神

ISO 8601

黄舟

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

大家讲道理

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

Peter_Zhu

请使用DateTime类来处理

Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template