Tuesday, January 19 2038. Time: 03:14:07 GMT

千年虫后还有虫  2038年问题

SkyUranus

网络时代，机会与危机共存，这也许是你我必须面对和必须付出的代价。“千年虫”解决之后，会不会有新的“虫”出现？回答是肯定的，“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位的电脑已经足够。

来自 http://us.rediff.com 的报道，观点略有不同：

Tuesday, January 19 2038. Time: 03:14:07 GMT. If Linux programmers get nightmares, it's about this date and time. Immediately after that second is crossed, current computer systems running on Linux will grind to a halt or go into a loop. This will trip up a lot of databases. No, this is not another hoax raised by some anti-Linux lobby. It is Linux's own Y2K nightmare, says Businessworld.

If you ask what this 2038 bug is, you will have to put up some technical argot. The bug has its origins in the way the C language, which has been used to write Linux, calculates time. C uses the 'time_t' data type to represent dates and times. ('time_t' is an integer that counts the number of seconds since 12.00 a.m. GMT,?January 1 1970.)

This data is stored in 32 bits, or units of memory. The first of these bits is for the positive or negative sign, and the remaining 31 are used to store the number. The highest number that these 31 bits can store works out to 2147483647.

Calculated from the start of January 1 1970, this number would represent the 2038 time and date given at the top. Problems would arise when the system times of computers running on Linux reach this number. They can't go any forward and their value actually would change to -- 2147483647, which translated to December 13 1901! That will lead many programs to return errors or crash altogether.

It's more damaging than the Y2K bug. That's because Y2K mostly involved higher-level applications such as credit card payment and inventory management. The 2038 bug, on the other hand, affects the basic time-keeping function.

"I would guess the biggest issue would be in the embedded field, where software isn't changed all that often, if at all. Process controllers, routers, mobile phones, game consoles, telecom switches and the like would be the biggest victims," says Raju Mathur, GNU and Linux consultant and president of the Linux Delhi Users Group.

He, however, adds that the rate at which we are changing technology, most systems are unlikely to use 32-bit processing by the time we get to 2038.

But what about the present? Many applications running on Linux could soon be making calculations for dates 30 years away -- say, for mortgage and insurance calculations -- and could start giving out error messages well before D-day. The problem could be widespread because more and more corporates today are migrating to Linux because of the better security it offers.

"The problem is not on the radar of most people, except the techies," says Charles Assissi, editor, Chip magazine.

How can the problem be sorted? Modern Linux programs could use 64-bit or longer time_t data storage to overcome the problem. As for the existing systems, the way the C language stores time_t data could be changed and then all the programs could be recompiled. All this is easier said than done.

"There must be millions, if not billions of lines of C code floating around that use the time_t value. Locating them, changing them, managing programs for which source isn't available, updating embedded systems, redeploying, is, in my opinion, an impossible task," says Mathur. Will that be another lucrative opportunity for India's army of coders?