3 个回答

那是32位系统才是,目前64位并不存在这个问题。

维基百科对于2038问题的解释

在计算机应用上,2038年问题可能会导致某些软件在2038年1月19日3时14分07秒之后无法正常工作。所有使用POSIX时间表示时间的程序都将受其影响,因为它们以自1970年1月1日经过的秒数(忽略闰秒)来表示时间。这种时间表示法在类Unix(Unix-like)操作系统上是一个标准,并会影响以其C编程语言开发给其他大部分操作系统使用的软件。在大部分的32位操作系统上,此“time_t”数据模式使用一个有正负号的32位整数(signed int32)存储计算的秒数。依照此“time_t”标准,在此格式能被表示的最后时间是2038年1月19日03:14:07,星期二(UTC)。超过此一瞬间,时间将会“绕回”(wrap around)且在内部被表示为一个负数,并造成程序无法工作,因为它们无法将此时间识别为2038年,而可能会依个别实现而跳回1970年或1901年。错误的计算及动作可能因此产生。

目前并没有针对现有的CPU/操作系统搭配的简单解决方案。直接将POSIX时间更改为64位模式将会破坏对于软件、数据存储以及所有与二进制表示时间相关的部分的二进位兼容性。更改成无符号的32位整数则会影响许多与两时间之差相关的程序。不过,那时使用32位系统的计算机可能会很少。

大部分64位操作系统已经把time_t这个系统变量改为64位宽。不过,其他现有架构的改动仍在进行中,不过预期“应该可以在2038年前完成”。然而,直到2006年,仍然有数以亿计的32位系统在运行中,特别是许多嵌入式系统。相对于一般电脑科技18至24个月的革命性更新,嵌入式系统可能直至使用寿命终结都不会改变。32位time_t的使用亦被编码于文件格式,例如众所周知的ZIP压缩格式。其能存在的时间远比受影响的机器长。

新的64位运算器可以记录至约2900亿年后的292,277,026,596年12月4日15:30:08,星期日(UTC)。

想想2000年的时候的千年虫事件吧,当时不是嘛事没有嘛

表示少年你多虑了,第一个你的程序肯定达不到22年的生命周期。
第二个你非要用int保存时间,就像有飞机坐,你非要游泳去美国,还问到时候游不到怎么办。

保存时间的的是MySQL数据库。而PHP只是取出字段用字符串操作。
MySQl中有多种表示日期和时间的数据类型。其中YEAR表示年份,DATE表示日期,TIME表示时间,DATETIME和TIMESTAMP表示日期和实践。它们的对比如下:

TEAR ,字节数为1,取值范围为“1901——2155”

DATE,字节数为4,取值范围为“1000-01-01——9999-12-31”

TIME,字节数为3,取值范围为“-838:59:59——838:59:59”

DATETIME,字节数为8,取值范围为“1000-01-01 00:00:00——9999-12-31 23:59:59”

TIMESTAMP,字节数为4,取值范围为“19700101080001——20380119111407”

当插入值超出有效取值范围时,系统会报错,并将零值插入到数据库中。

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题
宣传栏