“2038年”的新“虫”

“千年虫”解决之后，会不会有新的“虫”出现？回答是肯定的，“2038年”就是一个新的关卡。

 
网络时代，机会与危机共存，这也许是你我必须面对和必须付出的代价。“千年虫”解决之后，会不会有新的“虫”出现？回答是肯定的，“2038年”就是一个新的关卡。

也许大家都已经知道计算机的2000年问题是什么概念，但是什么时候又冒出来一个2038年问题的呢？

用C语言编制的程序不会碰到2000年问题，但是会有2038年问题。这是因为，大多数C语言程序都使用到一个叫做“标准时间库”的程序库，这个时间库用一个标准的4字节也就是32位的形式来储存时间信息。

当初设计的时候，这个4字节的时间格式把1970年1月1日凌晨0时0分0秒作为时间起点，这时的时间值为0。以后所有的时间都是从这个时间开始一秒一秒累积得来的。

比方说如果时间已经累积到了919642718这个数值，就是说这时距离1970年1月1日凌晨0时0分0秒已经过去了919642718秒，换算一下就应该是1999年2月21日星期天16时18分38秒。

这样计算时间的好处在于，把任意两个时间值相减之后，就可以很迅速地得到这两个时间之间相差的秒数，然后你可以利用别的程序把它换算成明白易懂的年月日时分秒的形式。

要是你曾经读过一点儿关于计算机方面的书，你就会知道一个4字节也就是32位的存储空间的最大值是2147483647，请注意！2038年问题的关键也就在这里———当时间一秒一秒地跳完2147483647那惊心动魄的最后一秒后，你猜怎么样？

答案是，它就会转为负数也就是说时间无效。那一刻的准确的时间为2038年1月18日星期一晚上10时14分7秒，之后所有用到这种“标准时间库”的C语言程序都会碰到时间计算上的麻烦。

这就是2038年问题。

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

说到这里，一些冰雪聪明的菜鸟DDMM们应该可以联想到，WindowsNT用的是64位操作平台，它的开始时间是1601年1月1日———但是它每过1个纳秒就跳一下，因此，WindowsNT它会碰到的是2184年问题……

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

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