去年 11 月，我列出了一系列“神奇数字”，其中包括一些时间/日期内容可能会被破坏的年份。 NTP 时代翻转有 2036 个，1 月份需要 32 位的 time_t 有 2038 个翻转，*以及 11 月的另一个 GPS 周翻转。
事实证明，我们还有一个更早的到来：2028 年！
看看今年会给你一个提示。现在是 2021 年，但另一种看待这一情况的方式是，我们已经过了 1900 年 121 年了。相当多的事物使用 1900 年作为纪元、基准年或只是某种偏移量。为什么？嗯，它们可能是在更简单的时代发明的，当时距 1900 年还不太远，而且它可以容纳更少的位。具体来说，到 2028 年，它只能容纳 7 位。
人们为什么要这么做？假设他们在当时的系统上可以使用的位有限。您至少需要 11 位来存储当前年份附近的值。而且，在当时看来，2028年可能还很遥远，根本不成问题，因为到时候这东西不可能还在用吧？
因此，如果有人使用 1900 年作为基准年，存储相对于此的年份，然后仅用七位（或八位，其中一位是符号位）来完成，那么它将在六年多一点的时间内溢出。接下来会发生什么取决于使用哪种方法，以及它是否应用某些类型的健全性检查。
最糟糕的情况是，我猜它可能会将“128 年”解释为“-127 年”，这将导致系统从 2027 年 12 月 31 日滚动到1773 年1 月 1 日。整洁的！
…
我最初发现这一点要归功于 HN 墓志铭 (!) 上的错误报告类型评论。那是关于 ISO 9660（CD/DVD 之类的东西）软件以及它如何处理年份的。
2015 年，在 Linux 内核中发现了类似的东西（并且似乎已经被修补）。
出于好奇，我去寻找更多信息，并确实找到了对同一问题的参考，如果您想让 HP 3000 保持活力，这些参考可能会很有用。您知道带有300 磅以上磁盘驱动器的东西吗？ （如果你知道，你就知道。）
除了这些页面之外，没有太多关于该主题的内容。
当然，维基百科在时间格式化和存储错误的史诗列表中确实有 2028 年，但它只谈论 70 年代的系统。它根本没有提到 ISO 9660——目前是这样。也许知情者会更新它，然后这个评论就会过时。
如果您负责一个可能以这种方式存储多年的位受限系统，那么您应该让每个人都去看看会发生什么。也许可以尝试将时间提前到 2028 年 1 月 1 日，看看它是否仍然快乐，或者是否决定去 18 世纪参加派对。
…
虽然我引起了你们的注意，但对于年轻人来说：只要我们谈论的是点点滴滴和岁月，你们就不一定是清楚的。您可能已经注意到，11 位将保存全年，就像 2021 年一样，不需要偏移。也许您甚至设计了一个系统，基于此将数据缩减至最小存储大小。
十一位！奢华！啊，好吧，猜猜2048年会发生什么？是的！
…
最后，对于那些还不知道的人来说，一件随机的事情：尝试 log2(n) 来感受一下二进制数有多大。很整洁，对吧？