原来是传说中的2038问题

  在若日历时间存放在带符号的3 2位整型数中，那么到哪一年它将溢出? 
           32位有符号整数，其实真正有用的只有31位，所以可以存储的时间是2^31秒，那么是多少年了，可以用如下公式
  粗略计算！
  y = 2^31/(365*24*60*60) (约)＝ 68! 而linux下时间是从1970开始的，所以到2038(1970+68)年，时间将会溢出！

 

 在计算机应用上，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年。错误的计算及动作可能因此产生。

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

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

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

 

下面的这个问题也和上面的问题差不多 

   在若进程时间存放在带符号的3 2位整型数中，而且每秒为1 0 0滴答，那么经过多少天后
该时间值将会溢出?

 

32位有符号整数，其实真正有用的只有31位，所以可以存储的时间是2^31下滴答，  y = 2^31/（24*60*60*100）＝ 248.55天