查看“2000 年问题”的源代码

[[文件:Bug_de_l'an_2000.jpg|thumb|300px|2000 年问题实例，法国南特中央理工学院的 LED 显示屏将 2000 年 1 月 3 日错误显示为 1900 年 1 月 3 日]]
2000 年问题（Year 2000 Problem，也称作 Millennium Bug 或 Year 2000 Bug，简称 Y2K），通常称作“千年虫问题{{efn|千年虫实际上是由 2000 年问题的英语名称 Millennium Bug 直译而来，在英语中，Bug 除了本义“虫子”之外，还可以指代计算机的程序问题，现如今也被作为程序术语使用。}}”，是一种计算机程序在日期表达上的设计缺陷。由于此设计缺陷，会导致计算机对于 2000 年及以后的年份识别错误，从而导致日期识别紊乱，令计算机执行任何与时间相关的任务时出现错误，进而影响计算机系统的运行。这类问题在老旧计算机上存在，在新计算机上不存在。在政府部门、军队、基础设施，以及许多重要行业中，大量老旧的计算机直到 2000 年还在持续工作。一旦工作在这些领域的计算机发生问题，可能导致小到停水、停电，大到银行瘫痪，乃至核电站事故和军械失控等一系列灾难性后果。

进入到 20 世纪 90 年代，2000 年问题逐渐通过媒体传播引起人们对它的关注，但是同时也引发了人们对此问题的恐慌。随后，针对此问题的全球性大规模修复开始，全世界为修复此问题前后在接下来的数年内累计投入约 3080 亿美元，在持续数年的修复之后，此问题最终得到有效解决，没有在新千年到来之际大规模爆发。

== 问题由来 ==
[[文件:IBM_1401_print_buffer.jpg|thumb|300px|1959 年推出的 IBM 1401 磁芯存储器模块。其 4 KB 容量的版本售价 20100 美元，相当于 2015 年时的 162000 美元]]
2000 年问题实际上并非电脑病毒，它只是一个计算机程序在日期表示上的缺陷，并不是一个恶意编写的电脑病毒。2000 年问题最早始于 20 世纪 50~60 年代，当时的计算机存储器价格极为昂贵，且容量很小，早期的磁芯存储器单位价格平均为 1 美元/比特，同时期一块容量仅为 1 MB 的硬盘价格为 761000 美元。当时的计算机极为早期，仍然使用打孔卡存储和输入数据，最常见的 IBM 打孔卡仅有 80 列宽，能够储存的数据也极其有限。正因为如此，程序员在编写程序时需要尽可能的节省存储空间，最大程度降低存储成本。因此，当时的程序员普遍在编写程序时使用六位数字存储时间，且只取年份中的后两位表示年份（例如，1976 年 10 月 29 日在这种格式下被简短存储为 {{code|29/10/76}} 或 {{code|10/29/76}}）。

在当时的情况下，使用六位数字表示日期的六位数日期表示法有一个很大的作用就算能够减小程序的内存需求，减少一个程序要占用的打孔卡卡数。这种做法实际上沿袭自更早之前的制表机时代，当时的操作人员就已经在打孔卡上使用六位数日期来节省时间和空间。在处理大量日期数据时，六位数日期表示法还可以发挥更大的作用。例如，一家拥有一千万客户，每个客户每天交易三次的银行如果要在计算机中存储一周之内所有客户的交易时间，只取两位数年份能够为银行节省 60 MB 的存储空间。

随着科技的发展，到了 20 世纪 70 年代，磁芯存储器的单位价格逐渐下降到 1 美分/比特，同时，同样价格，但是尺寸更小且更加便于使用的 DRAM 开始逐步替代磁芯存储器，打孔卡也同样逐渐被淘汰。存储技术的进步以及其价格的大幅降低，使得存储空间不再是一个紧迫的问题，在程序之中使用六位数日期的必要性也越来越低，但是并没有就此退出历史舞台。出于程序员们的习惯，并为了保持向上兼容，此种表示法继续沿用。即使当时就已经有人提出此种日期表示法潜在的问题，但是当时的程序员普遍都认为自己编写的程序不可能被持续使用到新千年，自然没有人理会这些警告。

六位数日期表示法虽然的确在节省存储空间上发挥了作用，但是这种模糊的表示方法也为未来埋下了隐患。人们在日常生活中为了方便有时也会只用两位数简称年份，但是计算机和人类的区别在于，人类拥有理解并补全前两位年份数字的能力，但是计算机没有这种能力。它们只会读取实际写出来的后两位年份，不会，也无法自行变更没有实际写出来的前两位年份数字。在六位数日期下，2000 年 1 月 1 日表示为 {{code|01/01/00}}，然而由于前两位没有实际写出来，自然也就无法自动变更。计算机始终会在这种情况下默认年份前两位为 19，这样会导致计算机将 2000 年错误认为是 1900 年，认为这个时候要早于 1999 年。这会引发计算机在涉及这部分的任务执行时出错，甚至崩溃。如果不对此问题进行修复，类似的故障将会在 2000 年到来时全球爆发，所有依赖这些老旧的计算机运作的基础设施、军政机关都会受到影响，导致轻则停电停水，重则医疗瘫痪，甚至导弹误射等一系列灾难性后果。

== 问题表现 ==
2000 年问题是由于程序设计缺陷产生的问题。最为显著的表现是，如前所述，在六位数日期下，2000 年 1 月 1 日将会被自动转换为 {{code|01/01/00}}。然而，由于前两位年份并没有被实际写出来，自然也就无法进行变更，计算机就会继续将年份的前两位默认为 {{code|19}}。如此一来，计算机就会错误的将 2000 年误认为是 1900 年，认为被缩写为 {{code|00}} 的 2000 年要早于被缩写为 {{code|99}} 的 1999 年。

2000 年问题并不仅限于 2000 年 1 月 1 日这个日期会造成影响，而且会导致计算机误判 2000 年及以后的年份，问题的根源实际上是计算机无法自动变更前两位的年份数字，由于无法自动变更，自然也会导致错误判定 1900 年以前的年份。某些使用数字 {{code|99}} 或 {{code|9999}} 作为文档的终止标记或停止代码，且仍然使用两位数表示年份的计算机可能会在 1999 年 9 月 9 日出现故障。此外，某些计算机使用了不正确的闰年识别方法，导致其无法将 2000 年正确识别为闰年，从而导致这些计算机在 2000 年 2 月 29 日、3 月 1 日、12 月 31 日，以及 2001 年 1 月 1 日出现故障。这样的问题也属于 2000 年问题的范畴。

除了上述的原因之外，导致 2000 年问题的原因也包括在程序编写时将 {{code|19}} 硬编码到软件子程序中、采用了可能致使存储寄存器溢出的日期数据类型。

=== 问题举例 ===
医生要使用计算机来为一名在 2000 年出生的婴儿计算要为他/她使用的药物剂量，若这台计算机仍然在使用六位数日期表示法，那么在这台计算机的逻辑中会错误的将这名婴儿误认为是一位出生于 1900 年的百岁老人，并向医生给出一个适用于老年人的药物剂量，而非新生儿的药物剂量，而此时给出的药物剂量对于一个新生儿来说可能是致命性的。
另一个例子是，税务部门为一家企业计算各类应缴税。由于使用六位数日期，2000 年会被转换为 00，在计算机的运行中，由于前两位被默认为 19，年份会变成 1900年，这就导致计算机会认为企业有 100 年没有缴税，企业的应缴税也将会从原本的几千到几十万瞬间变成企业无法承受的天文数字。

== 注 ==
{{notelist}}

== 另行参阅 ==
* [[2038 年问题]]

[[分类:扩展词条]]