广告
要点
- 2038年问题之所以发生，是因为C语言编程使用一个4字节整数来存储时间数据，该数据将在2038年1月19日溢出。
- 这种溢出是由于4字节有符号整数的最大限制为2,147,483,647秒，该限制从1970年1月1日（Unix系统的纪元日期）开始计算。
- 解决方案包括更新时间库，使其对时间值使用更大的字节大小，这被认为是比千年虫问题更容易解决的方案。
如今，大多数人都了解千年虫问题，因为它受到了大量的媒体关注。
大多数用C语言编写的程序相对不受千年虫问题的影响，但却受到2038年问题的困扰。这个问题之所以出现，是因为大多数C程序使用一个名为标准时间库的例程库。该库为时间值的存储建立了一个标准的4字节格式，并提供了许多用于转换、显示和计算时间值的函数。
标准的4字节格式假定时间起点是1970年1月1日凌晨12:00:00。这个值是0。任何时间/日期值都表示为从该零值开始的秒数。因此，值919642718表示从1970年1月1日凌晨12:00:00起经过919,642,718秒，即1999年2月21日（星期日）下午16:18:38的太平洋时间（美国）。这是一种方便的格式，因为如果你减去任意两个值，得到的就是它们之间的时间差（以秒为单位）。然后你可以使用库中的其他函数来确定两个时间之间经过了多少分钟/小时/天/月/年。
如果你读过位和字节的工作原理，你就会知道一个有符号的4字节整数的最大值为2,147,483,647，这就是2038年问题产生的原因。时间在回滚到负（无效）值之前的最大值是2,147,483,647，这相当于2038年1月19日。在这一天，所有使用标准时间库的C程序将开始在日期计算上出现问题。
幸运的是，这个问题比大型机上的千年虫问题更容易解决。编写良好的程序可以简单地用一个新版本的库重新编译，该库例如使用8字节值作为存储格式。这是可行的，因为该库将其所有时间活动都封装在自己的时间类型和函数中（与大多数大型机程序不同，它们没有标准化其日期格式或计算）。因此，2038年问题应该不会像千年虫问题那样难以解决。
广告
以下是一些有趣的链接
广告