跳转到内容

Year 2038 Problem：修订间差异

轻之舟百科，让知识轻装启航
以互动方式浏览历史
←上一编辑
撤销IdleTap-bot​（留言 | 贡献）
机器人
2,666次编辑
可视化wikitext
云云​（留言 | 贡献）
审核豁免用户、​行政员、​caellab、​管理员
2,775次编辑
创建页面，内容为“'''Year 2038 Problem'''（又称'''Y2038'''<ref name="enwiki">[https://en.wikipedia.org/wiki/Year_2038_problem Year 2038 Problem - Wikipedia]</ref>、'''Y2K38'''、'''Y2K38 superbug'''或'''Epochalypse'''<ref name=":0">[https://en.wikipedia.org/wiki/Year_2038_problem Year 2038 Problem - Wikipedia]</ref><ref name=":1">[https://graphsearch.epfl.ch/en/concept/300127 Year 2038 problem - EPFL]</ref>）是一个计算机系统中与时间表示相关的缺陷。该…”
IdleTap-bot​（留言 | 贡献）
机器人
2,666次编辑
由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）
 
第1行： 第1行：
'''Year 2038 Problem'''（又称'''Y2038'''<ref name="en[[wiki]]">[https://en.wikipedia.org/wiki/Year_2038_problem Year 2038 Problem - Wikipedia]</ref>、'''Y2K38'''、'''Y2K38 superbug'''或'''Epochalypse'''<ref name=":0">[https://en.wikipedia.org/wiki/Year_2038_problem Year 2038 Problem - Wikipedia]</ref><ref name=":1">[https://graphsearch.epfl.ch/en/concept/300127 Year 2038 problem - EPFL]</ref>）是一个[[计算机]]系统中与时间表示相关的缺陷。该问题源于部分系统使用'''有符号32位整数'''（signed 32-bit integer）来[[存储]]'''[[Unix]]时间'''（即自协调世界时（UTC）1970年1月1日00:00:00起经过的秒数）<ref name=":0" /><ref name=":2">[https://zh.wikipedia.org/wiki/Y2K38 2038年问题 - 维基百科]</ref>。由于32位有符号整数的最大值是2,147,483,647，其可编码的最终时间为2038年1月19日（星期二）03:14:07 UTC<ref name=":0" /><ref name=":2" />。若时间增加至下一秒（03:14:08），整数将发生'''溢出'''（overflow），数值变为负数，系统可能将时间误解为1901年12月13日20:45:52<ref name=":0" /><ref name=":2" />，进而引发各类[[软件]]故障<ref name=":0" /><ref name=":2" />。此问题与'''2000年问题'''（Y2K）类似，但后者源于十进制数的存储缺陷，而2038年问题源于[[二进制]]数的存储限制<ref name=":0" />。
'''Year 2038 Problem'''（又称'''Y2038'''<ref name="en[[wiki]]">[https://en.wikipedia.org/wiki/Year_2038_problem Year 2038 Problem - Wikipedia]</ref>、'''Y2K38'''、'''Y2K38 superbug'''或'''Epochalypse'''<ref name=":0">[https://en.wikipedia.org/wiki/Year_2038_problem Year 2038 Problem - Wikipedia]</ref><ref name=":1">[https://graphsearch.epfl.ch/en/concept/300127 Year 2038 problem - EPFL]</ref>）是一个[[计算机]]系统中与时间表示相关的缺陷。该问题源于部分系统使用'''有符号32位整数'''（signed 32-bit integer）来[[存储]]'''[[Unix]]时间'''（即自[[协调世界时]]（[[UTC]]）1970年1月1日00:00:00起经过的秒数）<ref name=":0" /><ref name=":2">[https://zh.wikipedia.org/wiki/Y2K38 2038年问题 - 维基百科]</ref>。由于32位有符号整数的最大值是2,147,483,647，其可编码的最终时间为2038年1月19日（星期二）03:14:07 UTC<ref name=":0" /><ref name=":2" />。若时间增加至下一秒（03:14:08），整数将发生'''溢出'''（overflow），数值变为负数，系统可能将时间误解为1901年12月13日20:45:52<ref name=":0" /><ref name=":2" />，进而引发各类[[软件]]故障<ref name=":0" /><ref name=":2" />。此问题与'''2000年问题'''（Y2K）类似，但后者源于十进制数的存储缺陷，而2038年问题源于[[二进制]]数的存储限制<ref name=":0" />。


{{Infobox
{{Infobox
| 标题 = Year 2038 Problem
| title = Year 2038 Problem
| 内容 =  
 
{{!}}-
| label1 = 中文名
! 中文名
| data1 = 2038年问题
{{!}} 2038年问题
 
{{!}}-
| label2 = 英文名
! 英文名
| data2 = Year 2038 Problem
{{!}} Year 2038 Problem
 
{{!}}-
| label3 = 别名
! 别名
| data3 = Y2038, Y2K38, Y2K38 superbug, Epochalypse, Unix Y2K
{{!}} Y2038, Y2K38, Y2K38 superbug, Epochalypse, Unix Y2K
 
{{!}}-
| label4 = 分类
! 分类
| data4 = 计算机时间表示缺陷
{{!}} 计算机时间表示缺陷
 
{{!}}-
| label5 = 发生时间
! 发生时间
| data5 = 2038年1月19日 03:14:07 UTC
{{!}} 2038年1月19日 03:14:07 UTC
 
{{!}}-
| label6 = 影响范围
! 影响范围
| data6 = 使用32位有符号整数存储Unix时间的系统
{{!}} 使用32位有符号整数存储Unix时间的系统
}}
}}
== 原因 ==
== 原因 ==

2026年8月11日 (二) 10:24的最新版本

Year 2038 Problem（又称Y2038[1]、Y2K38、Y2K38 superbug或Epochalypse[2][3]）是一个计算机系统中与时间表示相关的缺陷。该问题源于部分系统使用有符号32位整数（signed 32-bit integer）来存储Unix时间（即自协调世界时（UTC）1970年1月1日00:00:00起经过的秒数）[2][4]。由于32位有符号整数的最大值是2,147,483,647，其可编码的最终时间为2038年1月19日（星期二）03:14:07 UTC[2][4]。若时间增加至下一秒（03:14:08），整数将发生溢出（overflow），数值变为负数，系统可能将时间误解为1901年12月13日20:45:52[2][4]，进而引发各类软件故障[2][4]。此问题与2000年问题（Y2K）类似，但后者源于十进制数的存储缺陷，而2038年问题源于二进制数的存储限制[2]。

Year 2038 Problem
中文名2038年问题
英文名Year 2038 Problem
别名Y2038, Y2K38, Y2K38 superbug, Epochalypse, Unix Y2K
分类计算机时间表示缺陷
发生时间2038年1月19日 03:14:07 UTC
影响范围使用32位有符号整数存储Unix时间的系统

原因

[编辑 | 编辑源代码]

问题的根源在于Unix时间的存储方式。Unix时间定义为自协调世界时（UTC）1970年1月1日00:00:00（即Unix纪元）起所经过的秒数（忽略闰秒）[2][4]。在许多计算机系统中，尤其是基于C编程语言开发的系统，此时间值被存储在一个32位的有符号整数（`time_t`类型）中[4]。这种数据类型所能表示的最大值是231 - 1，即2,147,483,647[2][4]。这个最大值对应的UTC时间恰恰是2038年1月19日03:14:07[2][4]。当时间到达下一秒（03:14:08）时，整数值会增加到2,147,483,648，这超出了32位有符号整数的表示范围，从而引发整数溢出[2]。溢出后的数值会被解释为-231，对应1901年12月13日20:45:52 UTC[2][3]。系统因此无法识别正确的未来时间，可能导致程序运行异常或崩溃[2][4]。

受影响系统

[编辑 | 编辑源代码]

所有使用32位有符号整数存储Unix时间的系统都可能受到2038年问题的影响[2][4]。这主要包括：

  • 类Unix操作系统：如旧版的Linux、BSD、macOS等，以及它们之上的大量应用软件[4]。
  • 嵌入式系统：这些系统通常更新频率低或从不更新，是风险最高的领域之一，可能涉及工业控制系统、医疗设备、汽车电子、网络设备等[2][3]。
  • 使用C或C++等语言编写的、依赖系统时间进行日期计算或存储的旧版软件。

值得注意的是，部分系统在设计时使用了无符号32位整数（unsigned int32）来存储时间，这类系统的问题将推迟至2106年（即无符号32位整数溢出之年）才会显现[2][4]。例如，比特币区块链的时间戳即采用此方法[4]。

解决方案

[编辑 | 编辑源代码]

解决2038年问题的最根本方法，是将存储Unix时间的数据类型从32位迁移至64位[2][4]。一个64位有符号整数所能表示的时间范围极其广阔，其溢出将发生在约2920亿年后，远超宇宙的估计年龄[2][3]。

然而，这一迁移过程并非易事：

  • 软件兼容性：简单地更改time_t的定义会破坏现有软件的二进制兼容性（ABI），所有依赖时间计算的库和应用程序都需要为此重新编译和测试[4]。
  • 数据迁移：存储旧32位时间值的文件格式和数据库需要进行相应的升级和转换。
  • 硬件限制：部分老旧或定制的32位嵌入式系统可能无法直接升级至64位，需要更复杂的改造或替换方案。

因此，目前并没有一个放之四海而皆准的简单解决方案[4]。对于关键系统和设备，需要提前进行普查、评估和逐步替换。

类似问题

[编辑 | 编辑源代码]
  • 2000年问题（Y2K）：与本问题类似，但源于以两位十进制数表示年份所引发的世纪交替故障[2]。
  • 2106年问题：影响使用无符号32位整数存储Unix时间的系统[2]。
  • 其他时间相关溢出问题：例如，某些系统若使用不同的时间纪元（epoch）定义，其溢出时间点也会不同[2]。例如，使用CCSDS纪元（1958年）的系统可能在2026年即遭遇类似问题[2]。

参考文献

[编辑 | 编辑源代码]
  1. ↑ Year 2038 Problem - Wikipedia
  2. ↑ 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 Year 2038 Problem - Wikipedia
  3. ↑ 3.0 3.1 3.2 3.3 Year 2038 problem - EPFL
  4. ↑ 4.00 4.01 4.02 4.03 4.04 4.05 4.06 4.07 4.08 4.09 4.10 4.11 4.12 4.13 4.14 4.15 2038年问题 - 维基百科
检索自“https://130.wiki/index.php?title=Year_2038_Problem&oldid=6357”