担心PHP未来时间戳不够用的一次调查

结论:

64bit 系统,不用担心这个问题, 如果采用 32bit 系统,尽早升级。

调查过程

1.首先去了解了下 32bit64bit 的区别

  • 当Unix时间换为64位时,其最大时间对应的实际日期是一个极其遥远的未来时间点。

具体地,64位整数可以表示的最大值是2^63 - 1(因为通常时间戳是有符号的,所以要减去一个符号位)。这个值转换成秒数后,表示从1970年1月1日00:00:00 UTC开始经过的秒数。

  • 根据这个计算,64位Unix时间戳的最大值对应的日期是 292,277,026,596年12月4日15时30分08秒(UTC)。

  • 这个时间点已经远远超出了人类可以预见的未来,因此我们目前不需要担心会达到这个限制。

  • 归纳起来,64位Unix时间戳为我们提供了一个极其广阔的时间范围,足以满足未来很长时间内的需求。

2. 然后确认下 PHP time() 函数处理逻辑:

  • 在 PHP 中,time() 函数返回的是当前的 Unix 时间戳,它是一个整数。在 PHP 的大多数现代版本中,这个整数是 64 位的,即使底层的操作系统或硬件可能只支持 32 位整数。

  • PHP 在内部使用了一种称为“大整数”(bigint)或“长整数”(long)的类型来处理可能超出 32 位范围的整数。这确保了即使 Unix 时间戳超过了 32 位整数的范围,PHP 仍然能够正确地处理它。

  • 因此,你可以放心地使用 time() 函数,而不用担心它会在未来的某个时间点溢出。即使到了 2038 年(当 32 位 Unix 时间戳溢出时),PHP 的 time() 函数仍然能够正常工作,因为它返回的是 64 位整数。

3. 最担心的还是数据库,于是就查了下 MySQL 时间戳处理逻辑

  • MySQL 提供了多种保存时间的类型 , 这个问题与 TIMESTAMP 有关联

  • TIMESTAMP 字段类型可存储与时区无关的日期和时间,范围从’1970-01-01 00:00:01’ UTC到’2038-01-19 03:14:07’ UTC(对于32位系统)。这个时间戳是以秒为单位的整数,通常存储为4字节,因此可以认为是10位或11位的整数(取决于是否包含符号位)。

  • 在 MySQL 5.6.4 及更高版本中,TIMESTAMP 可以支持小数秒精度,即可以指定 TIMESTAMP(fsp),其中fsp是一个介于0到6之间的值,代表小数秒的位数。例如,TIMESTAMP(3)可以存储到毫秒级别的精度。

  • 请注意,由于 TIMESTAMP 的存储限制,它可能会在2038年达到其最大范围,之所以用可能是 32bit 系统就会达到最大范围。但由于 MySQL 8.0 引入了新的日期和时间类型,这个问题在较新的版本中得到了缓解。

  • 也就是 采用 64bit 系统的,不用担心这个问题, 如果采用 32bit 系统的,尽早升级吧。

本作品采用《CC 协议》,转载必须注明作者和本文链接
实干兴邦、力争上游
讨论数量: 5
yangweijie

所以数据库时间字段统一datetime 和date 就没问题了

3周前 评论
bigbug-gg (楼主) 3周前
fatrbaby

从来没担心过这个问题

3周前 评论

十年后的事情,还轮不到现在操心。

3周前 评论

先保证项目能活到这一天再说

3周前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!
未填写
文章
41
粉丝
13
喜欢
77
收藏
68
排名:286
访问:3.3 万
私信
所有博文
社区赞助商