2038年问题

http://www.guokr.com/post/638665/

在计算机应用上,2038年问题可能会导致某些软件在2038年无法正常工作。所有使用UNIX时间表示时间的程序都将受其影响,因为它们以自1970年1月1日经过的秒数(忽略闰秒)来表示时间。这种时间表示法在类Unix(Unix-like)操作系统上是一个标准,并会影响以其C编程语言开发给其他大部份操作系统使用的软件。

在大部份的32位操作系统上,此“time_t”数据模式使用一个有正负号的32位元整数(signedint32)存储计算的秒数。依照此“time_t”标准,在此格式能被表示的最后时间是2038年1月19日03:14:07,星期二(UTC)。超过此一瞬间,时间将会被掩盖(wrap around)且在内部被表示为一个负数,并造成程序无法工作,因为它们无法将此时间识别为2038年,而可能会依个别实作而跳回1970年或1901年。错误的计算及动作可能因此产生。

解决进展

但是大家也不用太过紧张。2038年问题比Y2K(Year 2000 Problem)[千年虫]问题解决起来相对要容易一些,只要给那些程序换一个新版本的“标准时间库”就可以了,比如说,改用8字节64位的形式来存储时间。这样做并不怎么费事,因为在C程序中“标准时间库”是相对独立的一个部分,里面的时间表达都有自己的一套时间类型和参数(而在碰到Y2K的那些大型主机中,时间格式大都没有一)。

而在一些用64位来表示时间的平台上,例如DigitalAlpha、SGI、Sparc等等,想要看到它们的时间出错你得等到天荒地老———那大概是2920亿年。到那时,位于猎户座旋臂的太阳,已经是黑矮星或暗黑物质,猎户座旋臂已经被重力波震断,银河系大概则已经变成小型似星体了。

所以,给那些准备攒机的菜鸟DD一个建议,除非您想要把资料流传给下一个宇宙,一台64位的电脑已经足够。

总之,32位的最后时间是2038年1月19日03:14:07,星期二。

64位的最后时间约2900亿年后的292,277,026,596年12月4日15:30:08,星期日。

Tagged with:

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*

*

code