大家一定还记得上个世纪末给IT业界带来不少麻烦的Y2K bug吧，很不幸的是，我们很快又将面临另一个和时间有关的bug——Y2038问题。

 

专家警告说，Y2038 bug将于2038年1月19日（星期二）03：14：07am（GMT）正式爆发，届时人们对千年虫问题的预言可能将一一实现，比如手机网络工作不正常，卫星脱离轨道，型号较老的电脑软件软硬件无法正常工作等。

 

什么是Y2038 bug

 

Time_t是C/C++ 等编程语言在内部代表/存储日期和时间的一种数据类型。Time_t实际上是一个代表秒数的整数，当它的值为0时，代表的时间是1970年1月1日12：00：00；当Time_t=60时，则表示1970年1月1日12：01：00，依此类推。

 

所有32位电脑系统都用带符号32位整型来存储time_t的值，也就是说t_time只能用31位二进制数来表示（第一位用来表示正负号），而其最大值转换为十进制是2147483647，换算成日期和时间刚好是2038年1月19日03：14：07am（GMT），而这一秒过后，t_time的值将变成-2147483647，代表的是1901年12月13日8：45：52pm，这样32位软硬件系统的日期时间显示就都乱套了。另外，无法接受time_t为负值的其他功能也将返回错误。

 

举个实际的例子来说，登陆上Yahoo messenger，给好友发个消息，恩没问题，现在把系统时间更改为2038年1月19日03：14：07am，此时如果再发消息Yahoo messenger就将崩溃。

 

为何担忧？

 

也许有人觉得2038年还早着，无需担心这个问题。不幸的是，上世纪60年代的程序开发人员也抱有类似的错误想法，并由此导致了Y2K问题，给全球IT页带来数十亿美元的损失。

 

要知道时间对于许多电脑程序来说都非常重要，操作系统、数据库程序、电子表格软件、实时控制系统等无不涉及到时间。因此我们必须在Y2038 bug爆发前做好充足的准备。

 

尽管到2038年，桌面PC和服务器基本上都将升级到64位甚至128位，但仍会有许多使用中的32位甚至更古老的系统。即使是在32位系统盛行的今天，大多数嵌入式系统仍是8位或16位的，而小型嵌入式系统的数量其实比台式机更多。

 

如何应对？

 

Y2038问题和Y2K一样难缠，其中一种解决办法就是用位数更多的数据类型来存储日期和时间。如果使用64位数据类型，time_t最大可以表示公元292000000000年，是宇宙估计年龄的20倍，最起码看到这篇文章的各位都不会再遇到什么YXXXX问题了。

 

目前对于Y2038 bug的影响有多大还存在争论，但有一点可以肯定的是：有备无患。相信我们能像克服Y2K问题那样圆满解决Y2038问题。
Remember the Y2k bug and the hype surrounding it? It seems the hype is back. Only this time, it is not about Y2k but about Y2038, the latest bug to take the virtual world by storm.

 

According to experts, in January 2038 many computers and electronic systems will come across a new date-related problem. This will create havoc among many systems around the globe. For example:
 

 

?Cellular networks could see interruption in normal operations;

 

?Life support systems in hospitals may collapse;

 

?Massive blackouts or brownouts may occur;

 

?Satellites in space may depart from their orbits;

 

?The 8/16-bit embedded systems will crash, and;

 

?Old software/hardware will be unable to perform efficiently.

 

Many of the predictions for the Y2K bug are likely to come true in the year 2038. The bug is predicted to hit exactly at 03:14:07GMT on Tuesday, Jan 19, 2038.

 

The Y2038 bug

 

Time_t is a data type used in C/C++ and other languages based on C/C++ to represent/store dates and times internally. Time_t is actually just an integer that counts the number of seconds since January 1, 1970, at 12:00am GMT. If time_t is set to 0, it means the date and time is Jan 1, 1970, 12:00:00am. If the value of time_t is 60, the date and time will be Jan 1, 1970, 12:01:00am, and so on.

 

On Jan 19, 2038, 03:14:07am GMT, the t_time value will be 2147483647. This is the problem. All 32-bit computer systems store time_t in signed 32-bit integer. In other words, time_t can use a maximum of 32 bits. The first bit is used to indicate positive or negative state of the number, while other 31 bits are used to store the number itself. We can store no more than 2147483647 in 31 bits.

 

Table 1 shows how on 19th Jan 2038, at 03:14:07, t_time will be set to 2147483647, which is the maximum number a 32-bit integer can store. Therefore, when t_time will hit the aforementioned value, 32-bit hardware/ software will be unable to handle date and time correctly.

 

When an integer reaches its maximum value and then gets incremented, it drops to its lowest possible negative value. This means if time_t value is set to 2147483647 and then increased by one, the value become negative 2147483648, which represents Dec 13, 1901, at 8:45:52pm.

 

Furthermore, other functions that use time_t cannot handle negative values and return an error.

 

Just to present a clearer picture, here is an example: Sign in to your Yahoo account using Yahoo messenger. Now check to see if you can send messages to your friends. Change your system抯 date to 19th Jan, 2038, 03:14:07 am and try sending an instant message. Your Yahoo messenger will crash.

 

Why worry?

 

Most people like to believe that the year 2038 is still far enough to begin worrying about the bug now.

 

Unfortunately, this is the same mistake the software developers of the 60s had made which resulted in the Y2k bug.

 

We have to keep in mind that 憈ime?is a highly prevalent factor in many computer applications. It is used in operating systems, database applications, spreadsheet software, real-time control systems and just about everywhere else. This makes it doubly important for us to ensure that we are well prepared before the bug finally hits the virtual world.

 

Although, all desktop PCs and servers will likely be 64-bit or even 128-bit ones by the year 2038, many systems may still be of 32-bit or less. Today a majority of the embedded systems are still 8-bit or 16-bit. The point is that small-embedded systems are more common than desktop computers.

 

What to do

 

This problem is not as difficult to resolve as the Y2K was. One can resolve this issue by using large data type to store date and time. In C language Long data type can store 64-bits. In a 64-bit program, time_t can represent maximum 292000000000 AD ?20 times the currently estimated age of the universe.

 

If you are a software developer, you can take these steps to avoid the year 2038 bug in your software:

 

?Always store data and time in large data types.

 

?Do not cast date and time from large data type to small data type.

 

?Use standard functions or APIs (Application programme interface) provided by operating systems to convert date and time. A few organizations have already begun using API in their software in order to avoid the bug.

 

?Use newer versions of compiler to compile your program.

 

Now that the issue has been cited, the developers will hopefully address it within the next ten to 20 years, and come out with a suitable solution. In that case, there is nothing much to worry about. But just to be on the safe side, you should at least distance yourself from functions related to time.

 

Although, there are conflicting reports on how dangerous the Y2038 bug is going to be, there is a consensus that it will create quite a stir for computer users. Precautions taken now can make a huge difference.