什么是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问题。

原文链接：http://www.dawn.com/weekly/science/science6.htm
译文来源：http://news.mydrivers.com/

================
看两条mydrivers的评论：

#1：由 秀一 第 #8 个发表的新闻评论
 
其实对于个人用户只是操作自己的电脑来完成一些文档，工作，娱乐和游戏，这个问题是没必要考虑的

但是世界上有太多电脑不是用来做这个的，那么问题就出来了，比如服务器，服务器上大部分都是Unix linux，当然windows的比重也很大，Unix/linux上时间一直是和文中介绍的那种方式来保存时间的，保存文件的时间我们可以忽略

而重要的是数据，比如一个论坛，里面有上亿帖，那么本来一个10位的时间现在没问题，到了2038，这个方式完全不能使用了，那么到时如果更换时间格式，或者加长这个数据的长度来修补这个问题的话，耗资都会和2000时一样巨大，比如一个帖子的发表时间用一个10位的数字来保存，修改时间一样用一个10位数字，假如加大位数，用12位，那么一个帖子增加了4位，一亿帖呢，有多少个论坛呢，有多少需要加长位数的数据呢，需要多少个硬盘来保存多出来的仅仅两位的数据呢 

#2：由 Muse 第 #5 个发表的新闻评论
 
这次肯定不会像2000年那么严重了，一方面上次千年虫已经解决了大部分，有2038问题的剩不了太多，其次，2038问题只要把第32位利用上就能够解决问题（延长到到2100年以后），根本不需要启用64位，2100年以后还会有人用32位的系统？那人类进步就有点太慢了吧~

其实千年中之所以引起那么大的影响，主要是当时太多（90%以上吧）都用2位数表示年，而全球规模的把两位变成4位确实影响很大，而2038问题只是修改一个变量所使用的数据类型重新编译即可解决问题，比2位年要简单得多，相对于千年虫，2038还是属于小问题的，只是和千年虫很相似罢了。

其实8000年后不是还要面临万年虫问题吗？人年几千年习惯于4位数的年，换成5位数的会适应？

其实不用再等800年，80年后可能还会面临这个问题，因为我们经历了千年虫，使用4位年数是理所应当的，但是现在已经开始有人在语言上习惯用04年、05年来表示2004、2005年了，很难想象10年、20年后人们是不是又会变回2位表示的年号？那时人们或许还会想，继十年后的事情，肯定好解决......谁知道呢~~

反正那时候我已经不在了