[2697] Y2K and 2038

Title Text:It’s taken me 20 years, but I’ve finally finished rebuilding all my software to use 33-bit signed ints.

Origin:https://xkcd.com/2697/

https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038

千年虫和2038

我花了20年,才终于重构了我的所有软件,以使用33位有符号整数²表示时间。

注释:
(1) 千年虫问题(Y2K bug)是指,早期计算机系统中使用两个数字表示年份, 如1999年表示为99,如此2000年可能会被误读为1900年,导致各类软件出错。
(2) 目前计算机系统中通常使用32位有符号整数 (32-bit signed integer)表示时间。2038年问题是指, 当UTC时间为2038年1月19日3时14分07秒时,下一秒数字会溢出为负数,导致各类软件出错。目前的解决方案是从32位改为64位 (而不是33位)。

http://xkcd.in/comic?lg=cn&id=2697

Y2K 错误,或更正式地说,2000 年问题,是由日历年的两位数软件表示错误处理 2000 年(例如将其视为 1900 或 19100)引起的计算机错误。2038年问题是一个类似的问题带有Unix 时间格式的时间戳,将在 2038 年 1 月 19 日溢出其带符号的 32 位二进制表示。

虽然最初估计 Y2K 问题需要大约 5000 亿美元才能解决,但人们早在几年前就已普遍认识到其潜在的严重性。包括计算机和软件制造商及其企业和政府用户在内的组织之间的共同努力反映出前所未有的合作、测试和增强受影响系统的成本大大低于早期估计。2000 年元旦,几乎没有发生重大错误。那些确实发生的问题通常不会中断基本流程或造成严重问题,而少数确实发生的问题通常会在几天到几周内得到解决。所涉及的软件代码审查允许纠正其他错误并提供各种增强功能,这通常至少部分弥补了纠正日期错误的成本。

目前尚不清楚 2038 年问题是否会及时得到有效解决,但 Y2K 错误的记录经验以及软件模块化和源代码访问的增加使得许多其他易受攻击的系统已经升级到更广泛的时间戳和日期格式,因此有有理由相信它可能更不重要和昂贵。2038的问题之前在607:2038887:未来时间线中已经提到过。

这部漫画假设 Y2K 和 Y2038 之间的 38 年应该平均分配在从 Y2K 中恢复和为 Y2038 做准备之间。那将把分裂点放在 2019 年。标题指出,现在是 2022 年,远远超过了那条分界线,所以每个人都应该完成他们的“Y2K 恢复”并开始为 2038 年做准备。不太可能有不止一些仍然受到 Y2K 错误影响的重要旧系统,因为为运行这个千禧年而构建的系统可以正确处理 1999 年之后的几年。Y2K 问题是否真的像人们认为的那样严重,这个话题仍然存在激烈的争论。主要论点属于“没有发生任何坏事,Y2K 绝对是一种不便而不是问题”与“。”只是因为在预防方面付出了巨大的努力”。这个问题不太可能有决定性的答案,事实可能介于这两个极端之间。无论这个问题的答案是什么,人们对这个问题的反应Y2K 确实导致了对清洁和面向未来的代码的重大推动,并提高了公众对这些代码的认识。

标题文本指的是用假设的新 33 位带符号整数时间和日期格式替换 32 位带符号的 Unix 时间格式,这不太可能,因为几乎所有现代计算机数据结构格式的分配都不比 8 位更精细字节。这样做对于新的软件开发人员来说可能看起来很复杂,但是使用更大的整数重新编译是Randall工程师解决 Y2K 错误的正常方法的一代,他们在计算机内存空间仍然非常宝贵时就学会了编码。花 20 年时间开发和实施这种格式并不完全适得其反,因为它会增加另外 68 年的功能,但与升级到广泛可用和受支持的 64 位 Unix 时间替换格式相比,它对资源的使用效率要低得多和软件兼容性库。

Leave a Reply

Your email address will not be published. Required fields are marked *

Categories