2006-1-23 19:41
大家一定还记得上个世纪末给IT业界带来不少麻烦的Y2K bug吧，很不幸的是，我们很快又将面临另一个和时间有关的bug——Y2038问题。
大家一定还记得上个世纪末给IT业界带来不少麻烦的Y2K bug吧，很不幸的是，我们很快又将面临另一个和时间有关的bug——Y2038问题。
专家警告说，Y2038 bug将于2038年1月19日（星期二）03：14：07am（GMT）正式爆发，届时人们对千年虫问题的预言可能将一一实现，比如手机网络工作不正常，卫星脱离轨道，型号较老的电脑软件软硬件无法正常工作等。
Y2038
●什么是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问题。
BTW：我自己在一台VIA C3＋Win98SE＋QQ上测试发送消息没有上面文章提示的崩溃问题。不会是那个64位CPU厂家的宣传文章吧。大家也测试一下看。
大家一定还记得上个世纪末给IT业界带来不少麻烦的Y2K bug吧，很不幸的是，我们很快又将面临另一个和时间有关的bug——Y2038问题。
专家警告说，Y2038 bug将于2038年1月19日（星期二）03：14：07am（GMT）正式爆发，届时人们对千年虫问题的预言可能将一一实现，比如手机网络工作不正常，卫星脱离轨道，型号较老的电脑软件软硬件无法正常工作等。
Y2038
●什么是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问题。
BTW：我自己在一台VIA C3＋Win98SE＋QQ上测试发送消息没有上面文章提示的崩溃问题。不会是那个64位CPU厂家的宣传文章吧。大家也测试一下看。
![[图片: index_43_XkYv08ijvQjN.jpg]](http://st.tfls.net/attachments/index_43_XkYv08ijvQjN.jpg)