2038年问题
2038年问题是指在使用POSIX时间的32位计算机应用程序上，格林尼治时间2038年1月19日凌晨03:14:07（北京时间：2038年1月19日中午11:14:07）之后无法正常工作。
因为它们的时间起点是格林尼治时间1970年1月1日0时0分0秒（这个时间名叫 the Unix Epoch），它们用the Unix Epoch经过的秒数（忽略闰秒）来表示时间。这种时间表示法在类Unix（Unix-like）操作系统上是一个标准，并会影响以其C编程语言开发给其他大部份操作系统使用的软件。
在大部分的32位操作系统上，此“time_t”数据模式使用一个有符号32位整数(signed int32)存储计算的秒数。依照此“time_t”标准，在此格式能被表示的最后时间是第2147483647秒（代表格林尼治时间2038年1月19日凌晨03:14:07）。下一秒，即格林尼治时间2038年1月19日凌晨03:14:08，由于32位整型溢出，时间将会被“绕回”（wrap around）成一个负数，变成了第 -2147483648 秒（代表格林尼治时间1901年12月13日20:45:52），造成应用程序发生严重的时间错误，而无法运行。
2038年问题比千年虫（the Millennium bug）问题解决起来相对要容易一些，只要给那些程序换一个新版本的“标准时间库”就可以了，比如说，改用8字节64位的形式来存储时间。
使用32位的数据类型来计算从新纪元开始的秒数，到2038年1月19日左右内核就会溢出。
使用64位内核时这个问题就消失了。因为使用64位的数据类型来计算从新纪元开始的秒数直到100亿年后才能溢出。
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。
