2038年虫
2025-10-15 20:49:37
发布于：湖南
网络时代，机会与危机共存。“千年虫”解决之后，会不会有新的“虫”出现？回答是肯定的，“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 语言程序都会碰到时间计算上的麻烦。
那你肯定要问了，为什么不用long long或者无符号整数（unsigned int）呢？
对于long long，早期计算机没有64位，大多数是16位或32位，long long在64位计算机上才有，所以早期开发者未考虑此方法。况且，time.h（ctime）要在2038年才会失效（32位）。
对于无符号整数（unsigned int），因为开发者考虑到了历史问题（无符号不能存储负数），所以开发者使用了有符号整数（int、signed int）。
因为以上两者，开发者在当时开发time.h（ctime）的时候，用了int。（现在win 11就是64位系统，所以系统日历不会出问题。但是应用如果是32位应用程序，那那个应用就会出问题。）
全部评论 8
d ddddddd dddddddd dddddddddd d d dd dd dd dd d d dd dd dd dd 加油！！ dd d ddd dd dd ddd dd ddd d dd dd dd dd dd
d d ddddddd dddddddd dddddddddd1周前 来自 上海
0d ddddddd dddddddd dddddddddd d d dd dd dd dd d d dd dd dd dd 加油！！ dd d ddd dd dd ddd dd dd d d dd dd dd dd dd d d ddddddd dddddddd dddddddddd1周前 来自 安徽
0
有帮助，赞一个