2038

        2038年一月19号，星期二，凌晨3点14分7秒钟的时候，如果Linux程序员会做恶梦的话，那么梦的内容一定是关于这个日期的，在这一秒钟滑过后，凡是安装着linux的计算机都会死机或者陷入死循环，这会给很多的数据库带来极大的麻烦。这个可不是那些反对linux的人胡编乱造得东东，而是linux自身的千年虫问题。

       如果你想知道什么是2038问题的话，你需要知道一些技术上的东西。这个bug是由用来写linux的c语言引起的，c中用time_t来代表时间和日期，time_t是整数（int）型的，它用来记载从1970年1月1日到目前所经历的秒数。

这个数据是以32位存储的，第一位是符号位，其余的31位用来存数字，而这31位数字可以存储的最大数字为2147483647

       从1970年开始计算，这31位的数字可以表示的秒数最多可以用到2038年，当时间到达这个数字的时候系统将会出现问题，到时候数字不会自动增加，而是会变为-2147483647，而这串数字代表的时间是1901年12月13号，这会导致很多的程序出现问题，甚至崩溃。

这个可比千年虫问题更具有破坏力，因为千年虫问题只会导致应用层的程序出现问题，比如信用卡支付系统，或者管理系统。而2038这个bug,将会影响系统最底层的时间控制的功能.

        Raju Mathur,GNU 和 Linux的顾问兼Linux Delhi Users Group的斑竹，说：“我认为到时候首当其冲的将会是嵌入式领域，因为这个领域内的软件更新不是很频繁。流程控制系统，手机，游戏平台，电话的交换机等等这类的设备将会是最大的受害者。”

        但是他后来补充道，以现在技术革新的速度，到时候估计不会有人还会使用32位的系统。

但是目前呢？很多运行在Linux上的程序可以计算到30年后的日期，对于抵押以及保险行业来说，可能在D-Day之前就会有问题出现。

         Charles Assissi，Chip杂志的编辑说：“这个问题目前还不会让很多人惊慌，除了那些脾气不好的人”。

        问题应该怎么分类解决呢？较新的Linux程序可以64位的或者更长的数据来表示时间，从而解决这个问题。对于现有的系统，可能c现在记录时间的方式将会被修改，然后所有的程序重新编译。作远远的要比说难得多。

       Mathur 说：“如果没有上10亿行的代码在使用这个值的话，至少也有上百万行，找到它们，修改他们，升级嵌入式的系统，然后再重新部署，我认为是一项不可能的任务。”这会不会是另一个对于印度的开发团队来说很好的机会呢？

 

 

 

编辑本段32位进制导致2038年问题

前言

　　 

  

2038年问题演示

在计算机应用上，2038年问题可能会导致某些软件在2038年无法正常工作。所有使用UNIX时间表示时间的程序都将受其影响，因为它们以自1970年1月1日经过的秒数（忽略闰秒）来表示时间。这种时间表示法在类Unix（Unix-like）操作系统上是一个标准，并会影响以其C编程语言开发给其他大部份操作系统使用的软件。在大部份的32位操作系统上，此“time_t”数据模式使用一个有正负号的32位元整数(signedint32)存储计算的秒数。依照此“time_t”标准，在此格式能被表示的最后时间是2038年1月19日03:14:07，星期二（UTC）。超过此一瞬间，时间将会被掩盖（wrap around）且在内部被表示为一个负数，并造成程序无法工作，因为它们无法将此时间识别为2038年，而可能会依个别实作而跳回1970年或1901年。错误的计算及动作可能因此产生。

 

　　“千年虫”解决之后，会不会有新的“虫”出现？回答是肯定的，“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月19日星期二晚上03:14:07，之后所有用到这种“标准时间库”的C语言程序都会碰到时间计算上的麻烦。

 

　　这就是2038年问题。

 

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

 

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

 

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

 

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

 

　　总之，32位的最后时间是2038年1月19日03:14:07，星期二。

 

　　64位的最后时间约2900亿年后的292,277,026,596年12月4日15:30:08，星期日。

 

编辑本段解决进展

　　目前并没有针对现有的CPU/操作系统搭配的简单解决方案。直接将POSIX时间更改为64位模式将会破坏对于软件、数据存储以及所有与二进制表示时间相关的部份的二进位兼容性。更改成无符号的32位运算器（integer）则会影响许多与时间改变相关的程序。

 

　　大部份64位操作系统已经把time_t这个系统变量改为64位宽。不过，其他现有架构的改动仍在进行中，不过预期“应该可以在2038年前完成”。然而，直到2006年，仍然有数以亿计的32位系统在运行中，特别是许多嵌入式系统。相对于一般电脑科技18至24个月的革命性更新，嵌入式系统可能直至使用寿命终结都不会改变。32位time_t的使用亦被编码于文件格式，例如众所周知的ZIP压缩格式。其能存在的时间远比受影响的机器长。

 

编辑本段64位进制可解决问题

　　新的64位运算器可以记录至约2900亿年后的292,277,026,596年12月4日15:30:08，星期日（UTC）。

 

   转自:

  http://blog.csdn.net/wxlinwzl/article/details/6952240