担心PHP未来时间戳不够用的一次调查
结论:
64bit
系统,不用担心这个问题, 如果采用32bit
系统,尽早升级。
调查过程
1.首先去了解了下 32bit
和 64bit
的区别
- 当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 协议》,转载必须注明作者和本文链接
推荐文章: